Switching Notes

IEEE 802.
1Q Tunneling
IEEE 802.1Q tunneling can be used to achieve simple layer two VPN connectivity between sites by
encapsulating one 802.1Q trunk inside another. The topology below illustrates a common scenario
where 802.1Q (or "QinQ") tunneling can be very useful.
A service provider has infrastructure connecting two sites at layer two, and desires to provide its
customers transparent layer two connectivity. A less-than-ideal solution would be to assign each
customer a range of VLANs it may use. However, this is very limiting, both in that it removes the
customers' flexibility to choose their own VLAN numbers, and there may not be enough VLAN
numbers (we can only use a maximum of 4,094 or so) available on large networks.
802.1Q tunneling solves both of these issues by assigning each customer a single VLAN number,
chosen by the service provider. Within each customer VLAN exists a secondary 802.1Q trunk, which is
controlled by the customer. Each customer packet traversing the service provider network is tagged
twice: the inner-most 802.1Q header contains the customer-chosen VLAN ID, and the outer-most
header contains the VLAN ID assigned to the customer by the service provider.
802.1Q Tunnel Configuration

Before we get started with the configuration, we must verify that all of our switches support the
necessary maximum transmission unit (MTU), 1504 bytes. We can use the command show system
mtu to check this, and the global configuration command system mtu to modify the device MTU if
necessary (note that a reload will be required for the new MTU to take effect).
S1# show system mtu
System MTU size is 1500 bytes
S1# configure terminal
S1(config)# system mtu 1504
Changes to the System MTU will not take effect until the next reload is done.
Next, we'll configure our backbone trunk to carry the top-level VLANs for customers A and B, which
have been assigned VLANs 118 and 209, respectively. We configure a normal 802.1Q trunk on both
ISP switches. The last configuration line below restricts the trunk to carrying only VLANs 118 and
209; this is an optional step.
S1(config)# interface f0/13
S1(config-if)# switchport trunk encapsulation dot1q
S1(config-if)# switchport mode trunk
S1(config-if)# switchport trunk allowed vlan 118,209

S2(config-if)# switchport trunk encapsulation dot1q
S2(config-if)# switchport mode trunk
S2(config-if)# switchport trunk allowed vlan 118,209
Now for the interesting bit: the customer-facing interfaces. We assign each interface to the appropriate
upper-level (service provider) VLAN, and its operational mode to dot1q-tunnel. We'll also enable
Layer two protocol tunneling to transparently carry CDP and other layer two protocols between the
CPE devices.
S1(config-if)# switchport access vlan 118
S1(config-if)# switchport mode dot1q-tunnel
S1(config-if)# l2protocol-tunnel
S1(config-if)# interface f0/3

S2(config-if)# interface f0/4
We can use the command show dot1q-tunnel on the ISP switches to get a list of all interfaces
configured as 802.1Q tunnels:
S1# show dot1q-tunnel
dot1q-tunnel mode LAN Port(s)

-----------------------------
Fa0/1
Fa0/3
Now that our tunnel configurations have been completed, each customer VLAN has transparent end-to-
end connectivity between sites. This packet capture shows how customer traffic is double-encapsulated
inside two 802.1Q headers along the ISP backbone. Any traffic left untagged by the customer (i.e.,
traffic in the native VLAN 1) is tagged only once, by the service provider.
2. Etherchannel Over Dot1q-tunnel
L2-Protocol Tunnels and 802.1q tunnels seems to be a topic that often confuse people and people
misunderstand the requirements to run these services.
The 802.1q tunnel feature allows a provider to tunnel customer traffic thru the provider network
without revealing the underlying L2 architecture of the provider network. In addition many customers
will likely share the same L2 VLAN’s thus there is a need to keep the customer VLAN traffic
separated.
With 802.1q tunneling the PE devices will add a second dot1q header, which is the access VLAN
configured on the switchport, to the customer traffic to allow the traffic to be tunneled thru the provider
cloud. This may be referred to as a Metro tag or double tagging traffic. Now obviously when you add
additional headers to traffic you need to account for these extra tags in the size of the frames. Meaning
make sure you remember to increase the system mtu of the devices to at least 1504, I personally
typically like to use 1508.
One pitfall to be aware of when configuring 802.1q tunnels is the native VLAN. If a customers native
VLAN is the same as the access VLAN configured for the tunnel port the Metro tag will not be added
to traffic of the native VLAN when using default 802.1q values on the Metro devices. There are two
ways to avoid this pitfall.
1. Use ISL trunking in the Metro Ethernet
2. Configure the Provider devices with the command “vlan dot1q tag native”. This causes the
native VLAN to also be tagged with the dot1q header on trunk ports.
It is also important to understand some of the limitations of 802.1q tunnels. Namely:
 They do not support carrying VTP, DTP, or CDP packets to the remote device
 Spanning-tree filtering is automatically enabled on the PE (Provider Edge) port.
 Layer 3 features on the PE ports are not supported such as L3 QoS and L3 ACL’s
 Fallback bridging is not supported for VLAN’s carrying customer traffic in the Metro Ethernet
Now to address a few of these shortcomings we have the additional L2 Protocol tunneling feature. The
L2 Protocol tunneling feature allows for traffic that would typically be terminated on the switchport for
evaluation to be carried to the remote PE (Provider Edge) port for evaluation by the remote customer
device. Such as:
 Spanning-tree traffic can now be carried between each site to allow for properly building the
spanning-tree topology between both sites.
 CDP packets can now be carried between devices to properly recognize the “Pseudo” connected
device.
 VTP can be carried between both sites
 LACP PAGP and UDLD traffic can be shared between two point-to-point interfaces.
If both Customer devices terminate on the same provider device L2 Protocol tunneling can be
used independently of 802.1q tunneling but if you must traverse more than 1 switch then the two
should be used in conjunction.
Example
So let’s work thru an example of configuring these two features with an EtherChannel between two
switches that is carried over a provider cloud. Below is a basic diagram of our topology we will work
with.
Now there are a few configuration requirements we should keep in mind as we work thru this example.
 System MTU on Metro Switches must be increased to 1504 or more. (Remember this needs a
reboot.)
 We are using 802.1q trunks so we need to command “vlan dot1q tag native”
Configuration
Following is the configuration for each device
Cat1
vlan 14
!
interface FastEthernet0/23
switchport trunk encapsulation dot1q
switchport mode trunk
udld port
channel-group 14 mode active
!
udld port
!
interface Vlan14
ip address 10.1.14.1 255.255.255.0
!
Cat2
vlan dot1q tag native
system mtu 1508
! ### remember reboot
!
spanning-tree portfast trunk
!
!
switchport access vlan 114
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel stp
l2protocol-tunnel vtp
l2protocol-tunnel point-to-point lacp
l2protocol-tunnel point-to-point udld
no cdp enable
!
no cdp enable
!
Cat3
vlan dot1q tag native
system mtu 1508
! ### remember reboot
!
!
!
no cdp enable
!
no cdp enable
!
Cat4
vlan 14
!
udld port
!
udld port
!
interface Vlan14
ip address 10.1.14.4 255.255.255.0
!
Let’s talk about a few of the key configuration components here. When I gave the background
information above on L2 Protocol Tunneling, note that LACP and UDLD are only support in a point-
to-point operation. This is the reason we used two different VLAN’s, 114 and 124, for the two ports
connected to the customer.
The L2 Protocol tunneling allows us to carry the CDP, LACP, spanning-tree, UDLD, and VTP packets
between Cat1 and Cat4. The 802.1q handles the carrying of the traffic between the two ports by adding
the Metro Tag of 114 and 124 to traffic coming in from Cat1 and Cat4 respectively.
The reason that running UDLD is important is we are load balancing traffic between two ports.
Because our neighboring device is not directly connected we need to be aware of a device failure on the
remote end. UDLD provides this function by testing the neighboring device and taking down a port in
the event of a failure on the remote end or in the provider path. You could compare this to FREEK in
reference to Frame-Relay technologies.
Now let’s test it out and see how things are working.
Cat1#show udld neighbors
Port Device Name Device ID Port ID Neighbor State
---- ----------- --------- ------- --------------
Fa0/23 CAT1029ZJBJ 1 Fa0/23 Bidirectional
Fa0/24 CAT1029ZJBJ 1 Fa0/24 Bidirectional
Cat1#show udld Fa0/23
Interface Fa0/23
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15
Time out interval: 5
Entry 1
---
Expiration time: 39
Device ID: 1
Current neighbor state: Bidirectional
Device name: CAT1029ZJBJ
Port ID: Fa0/23
Neighbor echo 1 device: CAT1029ZJD6
Neighbor echo 1 port: Fa0/23
CDP Device name: Cat4
Cat1#show udld Fa0/24
Interface Fa0/24
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Entry 1
---
Expiration time: 37
Device ID: 1
Current neighbor state: Bidirectional
Device name: CAT1029ZJBJ
Port ID: Fa0/24
Neighbor echo 1 device: CAT1029ZJD6
Neighbor echo 1 port: Fa0/24
CDP Device name: Cat4
Cat1#show spanning-tree vlan 14
VLAN0014
Spanning tree enabled protocol ieee
Root ID Priority 32782
Address 0019.0606.7180
Cost 12
Port 160 (Port-channel14)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32782 (priority 32768 sys-id-ext 14)
Address 0019.060c.5e80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po14 Root FWD 12 128.160 P2p
Cat1#show int trunk
Port Mode Encapsulation Status Native vlan
Po14 on 802.1q trunking 1
Port Vlans allowed on trunk
Po14 1-4094
Port Vlans allowed and active in management domain
Po14 1,14
Port Vlans in spanning tree forwarding state and not pruned
Po14 1,14
Cat1#ping 10.1.14.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.14.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms
Cat1#show cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
Cat4 Fas 0/24 121 S I WS-C3560- Fas 0/24
Cat4 Fas 0/23 120 S I WS-C3560- Fas 0/23
Cat1#show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
14 Po14(SU) LACP Fa0/23(P) Fa0/24(P)
Looks like it worked just as expected. Thanks for Reading.

3.Protected Ports and Port Blocking.
Posted on May 30, 2009 by David Sudjiman
Protected Ports
A protected port does not forward any traffic (unicast, multicast, or broadcast) to any other
port that is also a protected port. Data traffic cannot be forwarded between protected ports
at Layer 2; only control traffic, such as PIM packets, is forwarded because these packets are
processed by the CPU and forwarded in software. All data traffic passing between protected
ports must be forwarded through a Layer 3 device.
From the quote above, a protected port:

 Does not forward traffic to protected port.
 will still forward traffic to non-protected port.
 forward only packets that are processed by the CPU and forwarded in software.
 forward packets through a Layer 3 device.
4. FLEX LINKS
Flex Links is a layer 2 switch feature with which we can achieve redundancy and load balancing at
Layer 2 level, as an alternative to Spanning Tree Protocol (STP). Flex links are a pair of Layer 2
interfaces, such as switch ports or port channels, where one interface is configured as a backup to the
other. When the primary link goes down the backup link takes over traffic forwarding.
They can be configured on all switches that need redundancy, but typical place for them are in service
provider or enterprise networks where customers do not want to run STP on the switch.
Flex Link Examples:
Scenario 1: A Downlink Switch with one primary Uplink and a backup Uplink switches.
Scenario 2: Back to Back connected Switches with redundant connections.
Configuration & Operation

[1] It’s very simple to configure, but requires some manual effort. You need to identify which interface
is going to act as the primary active link and which is going to act as the backup link. Once it is
identified, assign the backup layer 2 interface [also called Flex link] as the backup to the primary Layer
2 interface. That’s it, Flex links are enabled in your setup.
Flex links are not enabled by default.
The backup link will be in standby mode [ready to begin traffic forwarding] until the primary link is up
and forwarding traffic. It will begin traffic forwarding if the other link shuts down. At any point of time
only one interface will be in linkup state and will be actively forwarding traffic. If the primary link
shuts down, the standby link takes up the duty and starts forwarding traffic. When the primary link
comes back up active, it goes into standby mode and does not participate in traffic forwarding.
Flex Links are supported only on Layer 2 ports and port channels, not on VLAN’s or on Layer 3 ports.
Preemption mode
We can make the primary link to be available at our our service when its link is up. This can be
achieved by preemption mechanism. Configure the Flex links pair with preemption mode. So one the
primary link comes back up, it will directly take over traffic forwarding by putting itself as active link
[with some pre-configured preemption delay]. The other link will be put back to standby [backup]
mode.
Load balancing
[2] Load balancing in Flex links work at VLAN level. Both the ports in the Flex link pair can be made
to forward traffic simultaneously. One port in the flex links pair can be configured to forward traffic
belonging to VLANs 1-50 and the other can forward traffic for VLANs 51-100. Mutually exclusive
VLANs are load sharing the traffic between the Flex link pairs. If one of the ports fails, the other active
link forwards all the traffic.
Flex links Vs STP

Flex links are easy to configure, highly efficient and more controllable feature but they require manual
effort which is not the case with Spanning Tree Protocol (STP). For larger networks with ever-changing
link layer network STP will be the only option. Flex links are more suitable and an opt choice for
service provider and core enterprise networks.
Spanning Tree Protocol is disabled on Flex Link interfaces.
5.1 Fallback Bridging
First off, thanks to the two sites below, i finally learned what this beast was about. Thanks guys!
Human Modem
CCIE Candidate
I got around to play with fallback bridging yesterday. I want to summarize its important points here.
To understand it in the first place, it helps to give some information on why its needed.
In using routed protocols, such as IP, we have the possibility of going across VLAN boundaries by
using ip routing between vlan interfaces. Using non-routed protocols such as IPX, Appletalk and other
legacy protocols, we dont have this option. Hence, if we want to be able to “speak” across VLAN
boundaries, we need fallback bridging.
Now, for the platforms. The 3550 switch regards all non-IPv4 traffic to be a candidate for fallback
bridging.
I state it this way, because the 3550 specifically, treats IPv6 traffic as non-IP traffic.
The 3560 switch is clever enough to treat IPv6 (and related traffic, such as NDP) as IP traffic, and
therefore not bridge it between VLANs.
Everything regarding fallback bridging is configured using bridge groups. We apply these bridge
groups to SVI’s and routed ports. Non-IP Traffic between these VLAN’s and routed ports can then
occur.
Configuration wise, its very simple:
1 Cat-1(config)# bridge 1 protocol vlan-bridge
2 Cat-1(config)# int vlan 200
3 Cat-1(config-int)# bridge-group 1
4 Cat-1(config)# int vlan 300
5 Cat-1(config-int)# bridge-group 1
Thats all there is to establish the bridge group and apply it to your VLAN’s.
Now after the initial configuration, there are a few things you can do to tweak access to the bridge. By
default the switch accepts connections from all mac addresses learned from the two (or more) VLAN’s.
You can disable this behavior like this:
1 Cat-1(config)# no bridge 1 acquire
After this, your bridge wont learn any addresses automatically
anymore. You then setup static assignments, on whether you want to
forward/deny specific mac entries. This is configured like so:
1 Cat-1(config)# bridge 1 address 0000.1111.1111 forward
The show command to verify your bridge is:
1 Cat-1#sh bridge 1
2 Br Group Mac Address State Type Ports
3 -------- ----------- ----- ---- -----
4 1 0000.1111.1111 Forward STATIC -
As shown, we have verified that we have statically assigned the 0000.1111.1111 mac address to be
forwarded through the bridge.
To test out this configuration (without the static, and allowing the bridge to automatically learn the mac
addresses), what you can do is set up two different VLAN’s, put a port into each, hook up a router to
each one and configure IPX on each router:
1 R1(config)# ipx routing
2 R1(config-if)# ipx network AAAA
3 R1(config-if)# mac-address 0000.1111.1111
4
5 R2(config)# ipx routing
6 R2(config-if)# ipx network AAAA
7 R2(config-if)# mac-address 0000.2222.2222
8
9 R1#ping ipx AAAA.0000.2222.2222
10
11 Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to AAAA.0000.2222.2222,
12
timeout is 2 seconds:
13 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
14
8/15/24 ms
And this is all successfull even though they are in separate VLAN’s.
I think thats all I have for fallback-bridging for now. Different stuff for me to say the least
5.2Fall Back Bridging Tutorial
Bridging is an obscure topic in CCIE R&S study.
It can be divided in three types
1) IRB (Integrated Routing and Bridging)

2) CRB (Concurrent Routing and Bridging
3) Fall back bridging
IRB is discussed in Lab 3 of internetworkExpert labs.
Basically IRB and CRB are generally used on routers to bridging different VLAN domains. If IRB is
used, we can route IP over these bridged interfaces. The topic that is least discussed is Fall Back
Bridging that we configure on switches. It is basically for non-IP traffic, and thats why chances of it
appearing on the LAB are slim.
But since nowadays obscure topics are my thing as I am pretty much done with the core, in fact back in
April Narbik and all my fellow bootcampers urged me to take the lab immediately saying that I was
more than ready and worried about things which I should not.
But my Lab date is September 18th and by that time, I want to be prepared in every thing. One of such
things is Fall Back bridging, so that if by chance it shows up, i am ready to tackle it.
Other topics about which Iĺl try to write tutorials are in my post below this one.
I’ll be demonstrating how fall-back bridging works using this example. SW1 has VLAN 11 and VLAN
22 defined and R1 and R2 are in VLAN 11 and 22 respectively. R3 and R4 are connected to switch
ports Fa0/3 and fa0/4 and I’ll be demonstrating how fall back bridging works using this example.
Topology Diagram:
SW1 is 3550.
3560 behaves identically
SW1 has VLAN 11 and VLAN 22 defined and R1 and R2 are in vlan 11 and 22 respectively.
R3 and R4 are connected to switch ports Fa0/3 and fa0/4 and VLANS are not defined.
For simplicity the mac-address are as follows.
R1 F0/0 = 0000.0000.001
R2 F0/0 = 0000.0000.002
R3 F0/0 = 0000.0000.003
R4 F0/0 = 0000.0000.004
Our goal here is to make all four router bridge the non-ip traffic between them where as R1 and R2 are
in VLAN 11 and 12 respectively and R3 and R4 are not in any vlan.
The configuration of switchports connecting to R1 and R2 are as follows

!
description To R1 F0/0
!
To enable bridging on the physical port first we have to issue no-switchport command on physical
interface.
Interface fa0/3 and fa0/4 here.
Here is the configuration of these ports.
!
no switchport
no ip address
!
no switchport
no ip address
end
Now we configure our fall back bridging.

For R1 and R2 the bridging will be configured under SVIs and for R3 and R4 under physical interface
SW1(config)#bridge 1 protocol vlan-bridge

SW1(config)#int vlan 11
SW1(config-if)#bridge-group 1
SW1(config-if)#int vlan 22
SW1(config-if)#int fa0/3
SW1(config-if)#int fa0/4
And we are done with simple fall back bridging.

For verification, we will simulate an IPX network.
SW1#sh bridge group

Bridge Group 1 is running the VLAN Bridge compatible Spanning Tree protocol
Port 25 (FastEthernet0/3) of bridge group 1 is forwarding
Port 26 (FastEthernet0/4) of bridge group 1 is forwarding
Port 22 (Vlan11) of bridge group 1 is forwarding
Port 23 (Vlan22) of bridge group 1 is forwarding
On R1:
R1(config)#ipx routing
R1(config)#int Fa0/0
R1(config-if)#ipx net
R1(config-if)#ipx netwo
R1(config-if)#ipx network ABC
R1(config-if)#ipx encapsulation sap
R1(config-if)#do sh ipx int f0/0
FastEthernet0/0 is up, line protocol is up
IPX address is ABC.0000.0000.0001, SAP
Similarly on R2, R3 and R4
Our IPX address are as follows
R1: ABC.0000.0000.0001
R2: ABC.0000.0000.0002
R3: ABC.0000.0000.0003
R4: ABC.0000.0000.0004
We will ping from R1 to all other routers and also monitor the bridge group table.
R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0002
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0002, timeout is 2 seconds:
!!!!!
R1#ping
Protocol [ip]: ipx
Repeat count [5]:
Verbose [n]:
!!!!!
R1#ping
Protocol [ip]: ipx
Repeat count [5]:
Verbose [n]:
!!!!!
Finally the bridging table on switch
SW1#sh bridge
Total of 300 station blocks, 296 free
Codes: P - permanent, S - self
Bridge Group 1:
Address Action Interface Age RX count TX count

0000.0000.0001 forward Vlan11 0 20 15
0000.0000.0002 forward Vlan22 0 10 5
0000.0000.0003 forward FastEthernet0/3 0 6 5
Now we’ll play with some features.
By default the mac-address are learned dynamically.

We can discard a mac-address, and force a router out of bridge group.
Lets discard R4’s mac address.
This will be done with the following command
SW1(config)#bridge 1 address 0000.0000.0004 discard

SW1#sh bridge
Bridge Group 1:

0000.0000.0001 forward Vlan11 2 20 15
0000.0000.0002 forward Vlan22 3 10 5
0000.0000.0004 discard - P 5 4
Now R1 should not be able to communicate with R4 but still be communicating with R2 and R3.
Lets test this.
R1#ping
Protocol [ip]: ipx
Repeat count [5]:
Verbose [n]:
.....
Success rate is 0 percent (0/5)
R1#ping
Protocol [ip]: ipx
Repeat count [5]:
Verbose [n]:
!!!!!
All right!
Now we can also change the behavior of dynamic learning by using “no bridge 1 acquire” command.
In that case, we have to manually add the mac-address we want to communicate with.
Lets do this and we’ll not manually add R2ś mac-address.
Weĺl see that R1 can ping R1 and R3 and R4 but not R2.
SW1(config)#no bridge 1 address 0000.0000.0004 discard

SW1(config)#no bridge 1 acquire
SW1(config)#do clear arp
SW1(config)#do sh bridge
All right all addresses have gone now.
Now we add
SW1(config)#bridge 1 address 0000.0000.0001 forward vlan 11

SW1(config)#bridge 1 address 0000.0000.0003 forward fastEthernet
SW1(config)#bridge 1 address 0000.0000.0004 forward
We can specify interface if we want, to avoid unnecessary broadcast. But this is not essential for
communication.
Let’s see the bridge table now.
SW1#sh bridge
Bridge Group 1:
0000.0000.0001 forward Vlan11 P 0 0
0000.0000.0002 discard Vlan22 0 0 0
0000.0000.0003 forward FastEthernet1/3 P 0 0
0000.0000.0004 forward - P 0 0
As you can see that R2 mac address is being discarded.

As after no bridge 1 acquire, we need to manually add the mac-adresses.
Now we ping from R1 to R2 and R3 and R4.
R1#ping
Protocol [ip]: ipx
Repeat count [5]:
Verbose [n]:
.....
Success rate is 0 percent (0/5)
R1#ping
Protocol [ip]: ipx
Repeat count [5]:
Verbose [n]:
!!!!!
Side Options:
Like spanning-tree we can modify forward time, hello time, and priority (for selecting root) by
following commands
bridge 1 forward-time
bridge 1 hello-time
bridge 1 priority
Also under the interface we can modify cost and priority to choose the path to root-bridge
SW1(config-if)#bridge-group 1 priority
SW1(config-if)#bridge-group 1 path-cost
Also aging time in bridge group table can be modified using

SW1(config)#bridge 1 aging-time ?
<10-1000000> Seconds
That’s pretty much it for fall back bridging.

For IRB (Integrated Routing and Bridging) and CRB (Concurrent Routing and Bridging) IE LAB 3 has
a good write-up, which should be enough for understanding
6. Point-to-Point Protocol over Ethernet
PPPoE and TCP/IP protocol stack

Application FTP SMTP HTTP … DNS …
Transport TCP UDP
Internet IP IPv6
PPP
Network access PPPoE
Ethernet
The Point-to-Point Protocol over Ethernet (PPPoE) is a network protocol for encapsulating Point-to-
Point Protocol (PPP) frames inside Ethernet frames. It is used mainly with DSL services where
individual users connect to the DSL modem over Ethernet and in plain Metro Ethernet networks. It was
developed by UUNET, Redback Networks and RouterWare and is available as an informational RFC
2516.
Ethernet networks are packet-based and have no concept of a connection or circuit and also lack basic
security features to protect against IP and MAC conflicts and rogue DHCP servers. By using PPPoE,
users can virtually "dial" from one machine to another over an Ethernet network, establish a point to
point connection between them and then securely transport data packets over the connection. It is
mainly used by telephone companies, since PPPoE is easily integrated with legacy dial-up AAA
systems and fits perfectly into the ATM backbones. The protocol also permits very easy unbundling of
DSLAMs where required by regulators, since the user would simply use a different login into PPP, then
the ATM circuit would be routed to the user's ISP. Also pre-paid traffic bucket business models can be
created with PPPoE more easily than with DHCP or multiplexing multiple users with different speed
tiers or QoS through 1 DSL modem or by creating a different login for each static IP purchased by
customers.
PPPoE faces a difficult future. MPLS/IP backbones and IP-DSLAMs are considered the norm and the
circuit switched family technologies (ATM/PDH) are being called legacy technologies[citation
needed]. Pseudowire and VoIP can be used to deal with legacy customers and equipment. PPPoE has
the highest overhead DSL delivery method.[1] The amount of overhead added by PPPoE depends on
the packet size because PPPoE adds 8 bytes to each packet.[2] If packets are large, say 1492 bytes, the
overhead is only 0.54 % ((1500-1492)/1492). If packets are small though, such as the traffic required
by certain web applications, VoIP or online games, the overhead can be much greater. As an example, if
a specific VoIP connection used a packet size of 60 bytes, a PPPoE connection adds a 15.3 % overhead.
[3] ATM, because of its overhead, is also being purged and PPPoE goes out with that. For example,
Verizon's FIOS product has converted to using DHCP internet access instead of PPPoE delivery.
GPON, an upgrade of BPON, added an alternative to ATM. PPPoE networks face difficulty in adding
multicasting and many level of QoS and lowest overhead for highest speeds for IPTV in today's
convergence and triple play networks.
How PPPoE fits in the DSL Internet access architecture

The transport protocol used on the telephone network is ATM. The DSL modem encapsulates PPP
packets inside ATM cells and sends them over the WAN. There are several encapsulation methods.
PPPoEoE
Ethernet packets containing the PPPoE packets are bridged over ATM (RFC 2684).
DSL Internet access architecture
Host PC DSL modem DSLAM Remote access server
IP IP
PPP PPP
PPPoE PPPoE
Ethernet Ethernet Ethernet Ethernet
ATM ATM
DSL DSL backbone backbone
PPPoE to PPPoA
The PPP frames are extracted from the PPPoE packets and encapsulated in ATM, thus converting
PPPoE into PPPoA (RFC 2364).
DSL Internet access architecture
Host PC DSL modem DSLAM Remote access server
IP IP
PPP PPP
PPPoE PPPoE PPPoA PPPoA
Ethernet Ethernet ATM ATM
DSL DSL backbone backbone
PPPoE stages
The PPPoE has two distinct stages:
PPPoE discovery
Since traditional PPP connections are established between two end points over a serial link or over an
ATM virtual circuit that has already been established during dial-up, all PPP frames sent on the wire are
sure to reach the other end. But Ethernet networks are multi-access where each node in the network can
access every other node. An Ethernet frame contains the hardware address of the destination node
(MAC address). This helps the frame reach the intended destination.
Hence before exchanging PPP control packets to establish the connection over Ethernet, the MAC
address of the two end points should be known to each other so that they can be encoded in these
control packets. The PPPoE Discovery stage does exactly this. In addition it also helps establish a
Session ID that can be used for further exchange of packets.
PPP session
Once the MAC address of the peer is known and a session has been established, the Session stage.
PPPoE Discovery (PPPoED)
Although traditional PPP is a peer-to-peer protocol, PPPoE is inherently a client-server relationship
since multiple hosts can connect to a service provider over a single physical connection.
The Discovery process consists of four steps between the host computer which acts as the client and the
access concentrator at the internet service provider's end. They are outlined below. The fifth and last
step is the way to close an existing session.
Client to server: Initiation (PADI)

PADI stands for PPPoE Active Discovery Initiation.[4]
If a user wants to dial up to the Internet using DSL, then his computer first must find the DSL access
concentrator (DSL-AC) at the user's Internet service provider's point of presence (POP).
Communication over Ethernet is only possible via MAC addresses. As the computer does not know the
MAC address of the DSL-AC, it sends out a PADI packet via an Ethernet broadcast (MAC:
ff:ff:ff:ff:ff:ff). This PADI packet contains the MAC address of the computer sending it.
Example of a PADI-packet:
Frame 1 (44 bytes on wire, 44 bytes captured)
Ethernet II, Src: 00:50:da:42:d7:df, Dst: ff:ff:ff:ff:ff:ff
PPP-over-Ethernet Discovery
Version: 1
Type 1
Code Active Discovery Initiation (PADI)
Session ID: 0000
Payload Length: 24
PPPoE Tags
Tag: Service-Name
Tag: Host-Uniq
Binary Data: (16 bytes)
Src. (=source) holds the MAC address of the computer sending the PADI.
Dst. (=destination) is the Ethernet broadcast address.
The PADI packet can be received by more than one DSL-AC. Only DSL-AC equipment that can serve
the "Service-Name" tag should reply.
Server to client: Offer (PADO)

PADO stands for PPPoE Active Discovery Offer.[5]
Once the user's computer has sent the PADI packet, the DSL-AC replies with a PADO packet, using the
MAC address supplied in the PADI. The PADO packet contains the MAC address of the DSL-AC, its
name (e.g. LEIX11-erx for the T-Com DSL-AC in Leipzig) and the name of the service. If more than
one POP's DSL-AC replies with a PADO packet, the user's computer selects the DSL-AC for a
particular POP using the supplied name or service.
Here is an example of a PADO packet:
Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0e:40:7b:f3:8a, Dst: 00:50:da:42:d7:df
PPP-over-Ethernet Discovery
Version: 1
Type 1
Code Active Discovery Offer (PADO)
Session ID: 0000
Payload Length: 36
PPPoE Tags
Tag: AC-Name
String Data: IpzbrOOl
Tag: Host-Uniq
Binary Data: (16 bytes)
AC-Name -> String data holds the AC name, in this case “Ipzbr001” (the Arcor DSL-AC in Leipzig)
Src. holds the MAC address of the DSL-AC.
The MAC address of the DSL-AC also reveals the manufacturer of the DSL-AC (in this case Nortel
Networks).
Client to server: Request (PADR)

PADR stands for PPPoE Active Discovery Request.[6]
A PADR packet is sent by the user's computer to the DSL-AC following receipt of an acceptable PADO
packet from the DSL-AC. It confirms acceptance of the offer of a PPPoE connection made by the DSL-
AC issuing the PADO packet.
Server to client: Session-confirmation (PADS)

PADS stands for PPPoE Active Discovery Session-confirmation.[7]
The PADR packet above is confirmed by the DSL-AC with a PADS packet, and a Session ID is given
out with it. The connection with the DSL-AC for that POP has now been fully established.
Either end to other end: Termination (PADT)

PADT stands for PPPoE Active Discovery Termination.[8]
This packet terminates the connection to the POP. It may be sent either from the user's computer or
from the DSL-AC.
Quirks
Since the point to point connection established has an MTU lower than that of standard Ethernet
(typically 1492 vs Ethernet's 1500), it can sometimes cause problems when Path MTU discovery is
defeated by poorly configured firewalls. Although higher MTUs are becoming more common in
providers' networks, usually the fix is to use TCP MSS (Maximum Segment Size) "clamping" or
"rewrite", whereby the access concentrator rewrites the MSS to ensure TCP peers send smaller
datagrams. Although TCP MSS clamping solves the MTU issue for TCP, other protocols such as ICMP
and UDP may still be affected. In practice, this does not present significant issues for residential users
since most content is served over TCP.
RFC 4638 allows PPPoE devices to negotiate an MTU of greater than 1492 if the underlying Ethernet
layer is capable of Jumbo Frames.
Some vendors (Cisco and Juniper, for example) refer to PPPoEoE (PPPoE over Ethernet), which is
PPPoE running directly over Ethernet or other IEEE 802 networks or over Ethernet bridged over ATM,
in order to distinguish it from PPPoEoA (PPPoE over ATM), which is PPPoE running over an ATM
virtual circuit using RFC 2684 and SNAP encapsulation of PPPoE. (PPPoEoA is not the same as Point-
to-Point Protocol over ATM (PPPoA), which doesn't use SNAP).

Switching Notes

Uploaded by

Copyright:

Available Formats

Switching Notes

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Switching Notes

Uploaded by

Copyright:

Available Formats

IEEE 802.

802.1Q Tunnel Configuration

S2(config)# interface f0/13

S2(config)# interface f0/2

dot1q-tunnel mode LAN Port(s)

Looks like it worked just as expected. Thanks for Reading.

From the quote above, a protected port:

Configuration & Operation

Flex links Vs STP

1) IRB (Integrated Routing and Bridging)

IRB is discussed in Lab 3 of internetworkExpert labs.

The configuration of switchports connecting to R1 and R2 are as follows

Now we configure our fall back bridging.

SW1(config)#bridge 1 protocol vlan-bridge

And we are done with simple fall back bridging.

SW1#sh bridge group

Address Action Interface Age RX count TX count

Now we’ll play with some features.

By default the mac-address are learned dynamically.

This will be done with the following command

SW1(config)#bridge 1 address 0000.0000.0004 discard

Address Action Interface Age RX count TX count

SW1(config)#no bridge 1 address 0000.0000.0004 discard

All right all addresses have gone now.

SW1(config)#bridge 1 address 0000.0000.0001 forward vlan 11

As you can see that R2 mac address is being discarded.

Also aging time in bridge group table can be modified using

That’s pretty much it for fall back bridging.

PPPoE and TCP/IP protocol stack

How PPPoE fits in the DSL Internet access architecture

Client to server: Initiation (PADI)

Server to client: Offer (PADO)

Client to server: Request (PADR)

Server to client: Session-confirmation (PADS)

Either end to other end: Termination (PADT)

You might also like