Posts Tagged ‘arp’

Mar
01

A key to the mastery of a CCENT-level of networking knowledge is to intimately understand the use of Layer 2 and Layer 3 addressing when two hosts communicate on the network.

This blog post will detail how these addresses are used during the network communications between two host devices (Personal Computers, PCs). Here is the topology that will be used in this example:
Continue Reading

Tags: , , , , ,

Jul
14

Due to the non-decreasing interest to the post about Private VLANs, I decided to make another one, more detailed – including a diagram and verification techniques.

Introduction

To begin with, recall that VLAN is essentially a broadcast domain. Private VLANs (PVANs) allow splitting the domain into multiple isolated broadcast “subdomains”, introducing sub-VLANs inside a VLAN. As we know, Ethernet VLANs can not communicate directly with each other – they require a L3 device to forward packets between separate broadcast domains. The same restriction applies to PVLANS – since the subdomains are isolated at Level 2, they need to communicate using an upper level (L3/packet forwarding) device – such as router.

In reality, different VLANs normally map to different IP subnets. When we split a VLAN using PVLANs, hosts in different PVLANs still belong to the same IP subnet, yet now they need to use a router (L3 device) to talk to each other (for example, by using Local Proxy ARP). In turn, the router may either permit or forbid communications between sub-VLANs using access-lists. Commonly, these configurations arise in “shared” environments, say ISP co-location, where it’s beneficial to put multiple customers into the same IP subnet, yet provide a good level of isolation between them.

Private VLANs Terminology

The following is the reference diagram that we are going to use to illustrate Private VLAN concepts and functionality.

Private VLANs

For our sample configuration, we take VLAN 1000 and divide it into three PVLANs – sub-VLAN 1012 (R1 and R2), sub-VLAN 1034 (R3 and R4) and sub-VLAN 1055 (router R5 only). Router R6 will be used as layer 3 device, to resolve the layer 3 communication issue. We name VLAN 1000 as “Primary” and classify the ports, assigned to this VLAN, based on their types:

  • Promiscuous (“P”) port: Usually connects to a router. This port type is allowed to send and receive L2 frames from any other port on the VLAN.
  • Isolated (“I”) port: This type of port is only allowed to communicate with “P”-ports – i.e., they are “stub” port. You commonly see these ports connecting to hosts.
  • Community (“C”) port: Community ports are allowed to talk to their buddies, sharing the same community (group) and to “P”-ports.

In order to implement sub-VLAN behavior, we need to define how packets are forwarded between different types of ports. We group the VLANs in “Primary” and “Secondary”.

  • Primary VLAN (VLAN 1000 in our example). This VLAN is used to forward frames downstream from “P”-ports to all other port types (“I” and “C” ports) in the system. Essentially, Primary VLAN embraces all ports in the domain, but only transports frames from the router to hosts (from “P” to “I” and “C”).
  • Secondary Isolated VLAN: forwards frames from “I” ports to “P” ports. Since Isolated ports do not exchange frames with each other, we can use just ONE isolated VLAN to connect all I-Port to the P-port.
  • Secondary Community VLANs: Transport frames between community ports (C-ports) within to the same group (community) and forward frames upstream to the P-ports of the primary VLAN.

How Private VLANs Work

Here are the key aspects of Private VLAN functioning:

  • The Primary VLAN delivers frames downstream from the router (promisc port) to all mapped hosts.
  • The Isolated VLAN transports frames from the stub hosts upstream to the router
  • The Community VLANs allow bi-directional frame exchange withing a single group, in addition to forwarding frames upstream towards “P”-ports.
  • Ethernet MAC address learning and forwarding procedure remain the same, as well as broadcast/multicast flooding procedure within boundaries of primary/secondary VLANs.

Private VLANs could be trunked. The secondary VLAN numbers are used to tag frames, just as with regular VLANs, and the primary VLAN traffic is trunked as well. However, you need to configure Private VLAN specific settings (bindings, mappings) on every participating swtich, as it’s not possible to use VTPv2 to dissiminate that information . This due to the fact that VTPv2 has no TLVs to carry private VLANs information. VTPv3 was designed to overcome this limitation among others.

Configuring Private VLANs

We have primary VLAN 1000, Isolated VLAN 1005 (R5) Community VLAN 1012 (R1, R2) and Community VLAN 1034 (R3, R4).

Step 1:

First, disable VTP, i.e. enable VTP transparent mode. After disabling VTP, create Primary and Secondary VLANs and bind them into PVLAN domain:

SW1:
vtp mode transparent
!
! Creating primary VLAN, which is shared among secondary’s
!
vlan 1000
  private-vlan primary

!
! Community VLAN for R1 and R2: allows a “subVLAN” within a Primary VLAN
!
vlan 1012
  private-vlan community
!
! Community VLAN for R3 and R4
!
vlan 1034
  private-vlan community

!
! Isolated VLAN: Connects all stub hosts to router.
! Remember - only one isolated vlan per primary VLAN.
! In our case, isolates R5 only.
!
vlan 1055
  private-vlan isolated

!
!  Associating the primary with secondary’s
!
vlan 1000
 private-vlan association 1012,1034,1055

This step is needed is to group PVLANs into a shared domain and establish a formal association (for syntax checking and VLAN type verifications). Repeat the same operations on SW2, since VTP has been disabled.

Step 2:

Configure host ports and bind them to the respective isolated PVLANs. Note that a host port belongs to different VLANs at the same time: downstream primary and upstream secondary. Also, enable trunking between switches, to allow private VLANs traffic to pass between switches.

SW1:
!
! Community port (links R1 to R2 and “P”-ports)
!
interface FastEthernet0/1
 description == R1
 switchport private-vlan host-association 1000 1012
 switchport mode private-vlan host
 spanning-tree portfast

!
! Community port (links R3 to R4 and “P”-ports)
!
interface FastEthernet0/3
 description == R3
 switchport private-vlan host-association 1000 1034
 switchport mode private-vlan host
 spanning-tree portfast

!
! Isolated port (uses isolated VLAN to talk to “P”-ports)
!
interface FastEthernet0/5
 description == R5
 switchport private-vlan host-association 1000 1055
 switchport mode private-vlan host
 spanning-tree portfast

!
! Trunk port
!
interface FastEthernet 0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk

SW2:
interface FastEthernet0/2
 description == R2
 switchport private-vlan host-association 1000 1012
 switchport mode private-vlan host
 spanning-tree portfast
!
interface FastEthernet0/4
 description == R4
 switchport private-vlan host-association 1000 1034
 switchport mode private-vlan host
 spanning-tree portfast

!
! Trunk port
!
interface FastEthernet 0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk

Next, Verify the configuration on SW1:

Rack1SW1#show vlan id 1012

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1012 VLAN1012                         active    Fa0/13

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1012 enet  101012     1500  -      -      -        -    -        0      0   

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------
1000    1012      community         Fa0/1

Rack1SW1#show vlan id 1034

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1034 VLAN1034                         active    Fa0/13

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1034 enet  101034     1500  -      -      -        -    -        0      0   

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------
1000    1034      community         Fa0/3

Rack1SW1#show vlan id 1055

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1055 VLAN1055                         active    Fa0/13

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1055 enet  101055     1500  -      -      -        -    -        0      0   

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------
1000    1055      isolated          Fa0/5

Rack1SW1#show interfaces fastEthernet 0/13 trunk 

Port        Mode         Encapsulation  Status        Native vlan
Fa0/13      desirable    802.1q         trunking      1

Port        Vlans allowed on trunk
Fa0/13      1-4094

Port        Vlans allowed and active in management domain
Fa0/13      1,1000,1012,1034,1055

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/13      1,1000,1012,1034,1055

Verify on SW2:

Rack1SW2#show vlan id 1000

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1000 VLAN1000                         active    Fa0/13

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1000 enet  101000     1500  -      -      -        -    -        0      0   

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------
1000    1012      community         Fa0/2, Fa0/6
1000    1034      community         Fa0/4, Fa0/6
1000    1055      isolated          Fa0/6

Rack1SW2#show vlan id 1012

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1012 VLAN1012                         active    Fa0/13

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1012 enet  101012     1500  -      -      -        -    -        0      0   

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------
1000    1012      community         Fa0/2, Fa0/6

Rack1SW2#show vlan id 1034

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1034 VLAN1034                         active    Fa0/13

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1034 enet  101034     1500  -      -      -        -    -        0      0   

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------
1000    1034      community         Fa0/4, Fa0/6

Rack1SW2#show vlan id 1055

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1055 VLAN1055                         active    Fa0/13

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1055 enet  101055     1500  -      -      -        -    -        0      0   

Remote SPAN VLAN
----------------
Disabled

Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------
1000    1055      isolated          Fa0/6

Rack1SW2#show interface fastEthernet 0/13 trunk 

Port        Mode         Encapsulation  Status        Native vlan
Fa0/13      desirable    802.1q         trunking      1

Port        Vlans allowed on trunk
Fa0/13      1-4094

Port        Vlans allowed and active in management domain
Fa0/13      1,1000,1012,1034,1055

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/13      1,1000,1012,1034,1055

Step 3:

Create a promiscuous port and configure downstream mappings. Here we add secondary VLANs for which traffic is received by this particular “P”-port. Primary VLAN is used to send traffic downstream to all “C” and “I” ports per their associations.

SW2:
!
! Promiscuous port, mapped to all secondary VLANs
!
interface FastEthernet0/6
 description == R6
 switchport private-vlan mapping 1000 1012,1034,1055
 switchport mode private-vlan promiscuous
 spanning-tree portfast

Verify the promiscuous port configuration:

Rack1SW2#show int fa 0/6 switch | beg private
Administrative Mode: private-vlan promiscuous
Operational Mode: private-vlan promiscuous
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: 1000 (VLAN1000) 1012 (VLAN1012) 1034 (VLAN1034) 1055 (VLAN1055)
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan:
  1000 (VLAN1000) 1012 (VLAN1012) 1034 (VLAN1034) 1055 (VLAN1055)

If you need to configure an SVI on a switch to communicate with private VLAN members, you should add an interface corresponding to Primary VLAN only. Obviously that’s because all secondary VLANs are “subordinates” of primary. After an SVI has been created, you have to map the required secondary VLANs to the SVI (just like with a promiscuous port) in order to make communications possible. You may exclude some mappings from SVI interface, and limit it to communicating only with certain secondary VLANs.

SW1:
!
! SW1 SVI is mapped to all secondary VLANs
!
interface Vlan 1000
 ip address 10.0.0.7 255.255.255.0
 private-vlan mapping 1012,1034,1055

SW2:
!
! SW2 SVI is mapped to 1012/1034 only, so it’s cant communicate with R5
!
interface Vlan1000
 ip address 10.0.0.8 255.255.255.0
 private-vlan mapping 1012,1034

Now to verify the configuration, configure R1-R6 interfaces in subnet “10.0.0.0/24” and ping broadcast addresses.

Rack1R1#ping 10.0.0.255 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.7, 4 ms
Reply to request 0 from 10.0.0.2, 4 ms
Reply to request 0 from 10.0.0.6, 4 ms
Reply to request 0 from 10.0.0.8, 4 ms

Rack1R3#ping 10.0.0.255 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.7, 4 ms
Reply to request 0 from 10.0.0.4, 4 ms
Reply to request 0 from 10.0.0.6, 4 ms
Reply to request 0 from 10.0.0.8, 4 ms

Rack1R5#ping 10.0.0.255 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.7, 1 ms
Reply to request 0 from 10.0.0.6, 1 ms

Rack1R6#ping 10.0.0.255 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.1, 4 ms
Reply to request 0 from 10.0.0.7, 4 ms
Reply to request 0 from 10.0.0.2, 4 ms
Reply to request 0 from 10.0.0.5, 4 ms
Reply to request 0 from 10.0.0.3, 4 ms
Reply to request 0 from 10.0.0.4, 4 ms
Reply to request 0 from 10.0.0.8, 4 ms

Lastly, there is another feature, called protected port or “Private VLAN edge”. The feature is pretty basic and is available even on low-end Cisco switches. It allows isolating ports in the same VLAN. Specifically, all ports in a VLAN, marked as protected are prohibited from sending frames to each other (but still allowed to send frames to other (non-protected) ports within the same VLAN). Usually, ports configured as protected are also configured not to receive unknown unicast (frame with destination MAC address not in switch’s MAC table) and multicast frames flooding for added security.

Example:

interface range FastEthernet 0/1 - 2
 switchport mode access
 switchport protected
 switchport block unicast
 switchport block multicast

Tags: , , , , , , , ,

Apr
24

GLBP, an acronym for Gateway Load Balancing Protocol, is a virtual gateway protocol similar to HSRP and VRRP. However, unlike its little brothers, GLBP is capable of using multiple physical gateways at the same time. As we know, a single HSRP or VRRP group represents one virtual gateway, with single virtual IP and MAC addresses. Only one physical gateway in a standby/redundancy group is responsible for packet forwarding, others remain inactive in standby/backup state. If you have R1, R2, R3 sharing the segment 174.X.123.0/24 with the physical IP addresses 174.X.123.1, 174.X.123.2 and 174.X.123.3 you may configure them to represent one single virtual gateway with an IP address 174.X.123.254. The physical gateway priority settings will determine which physical gateway takes the role of the active packet forwarder. The hosts on the segment will set their default gateway to 174.X.123.254, staying isolated of the physical gateway failures.

GLBP brings this idea to new level, by allowing multiple physical gateways to participate in packet forwarding simultaneously. Considering the example above, imagine you need the hosts on the segments to fully utilize all existing physical gateways, yet provide recovery from a gateway failure. For instance, you may want 50% of outgoing packets to be sent up to R1, 30% to R2 and 20% to R3. At the same time, you want to ensure, that hosts using either of the gateways will automatically switch to another if their gateway fails. On top of that, all hosts in the segment should reference to the virtual gateway using the same IP address 174.X.123.254. This is a complicated task, which has being addressed by GLBP protocol design.

To begin with, we should recall that every host on the segment needs to resolve the virtual gateway IP address 174.X.123.254 to the MAC address using ARP protocol. When we use HSRP or VRRP, the ARP response will be the virtual MAC addresses, which is assigned to the active physical gateway. At this point, GLBP responds with different virtual MAC addresses of the physical gateways in the GLBP group. So the key idea with GLBP is accomplishing load-balancing by responding to ARP requests with different virtual MAC addresses.

Here are the implementation details. One of the routers in a GLBP group is elected as an AVG – Active Virtual Gateway. There is only one active AVG in a group, and its task is to respond to ARP requests sent to the virtual gateway IP address (e.g. 174.X.123.254) replying different virtual MAC addresses in response packets. The AVG will also implement load-sharing algorithm, e.g. by sending the replies in proportion to weights configured for physical gateways. Aside from AVG, the other logical component of GLBP implementation is AVF – Active Virtual Forwarder. Any physical gateway in a GLBP group may act as AVF – in fact all physical gateways are usually AVFs. Every AVF has a virtual MAC address assigned by an AVG and a weight value configured by an operator.

Now let’s discuss redundancy – the primary goal of any virtual router protocol. There are two logical entities used to build a GLBP group: AVGs and AVFs, and each of them needs a backup scheme. Since there is just one AVG per a GLBP group, the procedure is pretty simple: each candidate AVG has a priority value assigned; the highest priority router becomes an active AVG, the next by priority becomes a standby AVG. You may configure AVG preemption, so that a newly configured router with highest priority value becomes AVG, preemption the old one.

What about AVF redundancy? First, we need to understand that AVFs are always “active” in the sense that they are always used by a load-balancing algorithm. (However, by setting an AVG weight value below threshold, we may effectively take the AVF out of service. The weight value could be combined with object tracking to bring powerful traffic manipulation options). Next, with respect to redundancy, all AVFs backup each other. For instance, take any AVF: with respect to the other AVFs it is “Active”, and the remaining AVFs are in “Listen” state. If the AVF would fail, other gatewyas will detect the event using Hold timer expiration, and immediately try to take over the failed AVF virtual MAC address. Among the competitors, the AVF with highest weight value would win, and the remaining AVFs will switch back to “Listen” state. At this point, the “winner” will start accepting packets for two virtual MAC addresses: it’s own, and the one it has obtained from the failed AVF. At the same moment, two timers would start: Redirect and Secondary Hold. The Redirect timer determines how long will AVG continue to respond to ARP requests with the virtual MAC of the failed AVF. The Secondary Hold timer sets the amount of time the backup AVF will continue to accept packet for the virtual MAC address taken from the failed AVF.

This is basically how GLBP works. Different load-balancing algorithms are supported – the default one is round robin, with options for weighted load balancing and source-MAC based. The last one will always respond with the same vMAC to the same source MAC address, thereby defining sort of host-gateway “stickiness”. Now for a sample GLBP configuration, for the above mentioned R1, R2 and R3:

!
!  We set load-balancing to weighted only on R1
!  So if R2 will become the AVG, it will use round-robin
!  load-balancing technique
!
R1:
interface FastEthernet0/0
 ip address 174.1.123.1 255.255.255.0
 glbp 123 ip 174.1.123.254
 glbp 123 preempt
 glbp 123 weighting 50
 glbp 123 load-balancing weighted
!
!
!
R2:
interface FastEthernet0/0
 ip address 174.1.123.2 255.255.255.0
 glbp 123 ip 174.1.123.254
 glbp 123 priority 50
 glbp 123 preempt
 glbp 123 weighting 30
!
!
!
R3:
interface Ethernet0/0
 ip address 174.1.123.3 255.255.255.0
 glbp 123 ip 174.1.123.254
 glbp 123 priority 25
 glbp 123 preempt
 glbp 123 weighting 20

Some show output:

Rack1R1#show glbp
FastEthernet0/0 - Group 123
  State is Active
    2 state changes, last state change 03:12:05
  Virtual IP address is 174.1.123.254
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.916 secs
  Redirect time 600 sec, forwarder time-out 14400 sec
  Preemption enabled, min delay 0 sec
  Active is local
  Standby is 174.1.123.2, priority 50 (expires in 8.936 sec) <-- Standby AVG
  Priority 100 (default)
  Weighting 50 (configured 50), thresholds: lower 1, upper 50 <--
<-- Should the weight go below thresh, AVF is taken offline
  Load balancing: weighted
  Group members:
    ca00.0156.0000 (174.1.123.1) local <--   Hardware MACs
    ca01.0156.0000 (174.1.123.2)
    cc02.0156.0000 (174.1.123.3)
  There are 3 forwarders (1 active)
  Forwarder 1
    State is Listen <--  All other AVFs Listen to us
    MAC address is 0007.b400.7b01 (learnt) <--  Virtual MAC 
    Owner ID is ca01.0156.0000 <--  This is R2
    Redirection enabled, 598.928 sec remaining (maximum 600 sec) <--
<-- ARP replies with this vMAC are being sent by AVG
    Time to live: 14398.376 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 174.1.123.2 (primary), weighting 30 (expires in 8.368 sec) <--
   <--  The AVF reports it’s own IP as active
    Arp replies sent: 1
  Forwarder 2
    State is Active <--  Active mean it’s us
      1 state change, last state change 03:12:45
    MAC address is 0007.b400.7b02 (default)
    Owner ID is ca00.0156.0000 <--  R1 MAC address
    Redirection enabled
    Preemption enabled, min delay 30 sec
    Active is local, weighting 50
    Arp replies sent: 1
  Forwarder 3
    State is Listen <--  All other AVFs Listen to us
    MAC address is 0007.b400.7b03 (learnt)
    Owner ID is cc02.0156.0000 <--  This is R3
    Redirection enabled, 597.916 sec remaining (maximum 600 sec)
    Time to live: 14397.916 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 174.1.123.3 (primary), weighting 20 (expires in 7.916 sec)

Rack1R2#show glbp
FastEthernet0/0 - Group 123
  State is Standby
    4 state changes, last state change 03:16:56
  Virtual IP address is 174.1.123.254
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.236 secs
  Redirect time 600 sec, forwarder time-out 14400 sec
  Preemption enabled, min delay 0 sec
  Active is 174.1.123.1, priority 100 (expires in 9.148 sec)
  Standby is local <-- We are the standby AVG
  Priority 50 (configured)
  Weighting 30 (configured 30), thresholds: lower 1, upper 30
  Load balancing: round-robin
  Group members:
    ca00.0156.0000 (174.1.123.1)
    ca01.0156.0000 (174.1.123.2) local
    cc02.0156.0000 (174.1.123.3)
  There are 3 forwarders (1 active)
  Forwarder 1
    State is Active
      1 state change, last state change 03:18:06
    MAC address is 0007.b400.7b01 (default)
    Owner ID is ca01.0156.0000 <-- This is R2
    Preemption enabled, min delay 30 sec
    Active is local, weighting 30
  Forwarder 2
    State is Listen
    MAC address is 0007.b400.7b02 (learnt)
    Owner ID is ca00.0156.0000
    Time to live: 14398.644 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 174.1.123.1 (primary), weighting 50 (expires in 8.636 sec)
  Forwarder 3
    State is Listen
    MAC address is 0007.b400.7b03 (learnt)
    Owner ID is cc02.0156.0000
    Time to live: 14399.260 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 174.1.123.3 (primary), weighting 20 (expires in 9.260 sec)

Now let’s check how ARP redirection works:

Rack1SW1#ping 174.1.123.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 174.1.123.254, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 8/12/16 ms

Rack1SW1#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  174.1.123.254           0   0007.b400.7b01  ARPA   Vlan1
Internet  174.1.123.7             -   cc06.0156.0000  ARPA   Vlan1
Internet  174.1.123.2             0   ca01.0156.0000  ARPA   Vlan1
Rack1SW1#clear arp-cache 

Rack1SW1#ping 174.1.123.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 174.1.123.254, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/13/32 ms

Rack1SW1#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  174.1.123.254           0   0007.b400.7b02  ARPA   Vlan1
Internet  174.1.123.7             -   cc06.0156.0000  ARPA   Vlan1
Internet  174.1.123.2             0   ca01.0156.0000  ARPA   Vlan1

Repeat the above actions a few more times

Rack1SW1#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  174.1.123.254           0   0007.b400.7b03  ARPA   Vlan1
Internet  174.1.123.7             -   cc06.0156.0000  ARPA   Vlan1
Internet  174.1.123.2             0   ca01.0156.0000  ARPA   Vlan1
Internet  174.1.123.3             0   cc02.0156.0000  ARPA   Vlan1

To summarize, GLBP is a virtual gateway protocol, with built-in load-balancing capabilities. Load balancing is based on manipulating ARP responses to the requests sent to the virtual gateway IP address. AVG role is used to load-balance and respond to ARP requests. AVF role manages one or more virtual MACs and is responsible for packet forwarding. AVG redundancy is controlled by GLBP priority and AVF redundancy is implemented using AVF weight value and two additional timers.

Further reading:

GLBP Overview

Tags: , , , , ,

Jan
31

You may want to see the updated version of this post at:

http://blog.internetworkexpert.com/2008/07/14/private-vlans-revisited/

Private VLAN concepts are quite simple, but Cisco’s implemenation and configuration steps are a bit confusing – with all the “mappings” and “associations” stuff. Here comes a short overview of how private VLANs work.

To begin with, let’s look at the concept of VLAN as a broadcast domain. What Private VLANs (PVANs) do, is split the domain into multiple isolated broadcast subdomains. It’s a simple nesting concept – VLANs inside a VLAN. As we know, Ethernet VLANs are not allowed to communicate directly, they need L3 device to forward packets between broadcast domains. The same concept applies to PVLANS – since the subdomains are isolated at level 2, they need to communicate using an upper level (L3 and packet forwarding) entity – such as router. However, there is difference here. Regular VLANs usually correspond to a single IP subnet. When we split VLAN using PVLANs, hosts in different PVLANs still belong to the same IP subnet, but they need to use router (another L3 device) to talk to each other (for example, by means of local Proxy ARP). In turn, router may either permit or forbid communications between sub-VLANs using access-lists.
Why would anyone need Private VLANs? Commonly, this kind of configurations arise in “shared” environments, say ISP co-location, where it’s beneficial to put multiple customers into the same IP subnet, yet provide a good level of isolation between them.

For our sample configuration, we will take VLAN 100 and divide it into two PVLANs – sub-VLANs 101 and 102. Take the regular VLAN and call it primary (VLAN 100 in our example), then divide ports, assigned to this VLAN, by their types:

Promiscuous (P): Usually connects to a router – a type of a port which is allowed to send and receive frames from any other port on the VLAN
Isolated (I): This type of port is only allowed to communicate with P-ports – they are “stub”. This type of ports usually connects to hosts
Community (C): Community ports are allowed to talk to their buddies, sharing the same group (of course they can talk to P-ports)

In order to implement sub-VLAN behavior, we need to define how packets are forwarded between different port types. First comes the Primary VLAN – simply the original VLAN (VLAN 100 in our example). This type of VLAN is used to forward frames downstream from P-ports to all other port types (I and C ports). In essense, Primary VLAN entails all port in domain, but is only used to transport frames from router to hosts (P to I and C). Next comes Secondary VLANs, which correspond to Isolated and Community port groups. They are used to transport frames in the opposite direction – from I and C ports to P-port.

Isolated VLAN: forwards frames from I ports to P ports. Since Isolated ports do not exchange frames with each other, we can use just ONE isolated VLAN to connect all I-Port to the P-port.
Community VLANs: Transport frames between community ports (C-ports) within to the same group (community) and forward frames uptstream to the P-ports of the primary VLAN.

This is how it works:

Primary VLANs is used to deliver frames downstream from router to all hosts; Isolated VLAN transports frames from stub hosts upstream to the router; Community VLANs allow frames exchange withing a single group and also forward frames in upstream direction towards P-port. All the basic MAC address learning and unknown unicast flooding princinples remain the same.

Let’s move to the configuration part (Primary VLAN 100, Isolated VLAN 101 and Community VLAN 102).

Step 1:

Create Primary and Secondary VLANs and group them into PVLAN domain:

!
! Creating VLANs: Primary, subject to subdivision
!
vlan 100
 private-vlan primary

!
! Isolated VLAN: Connects all stub hosts to router
!
vlan 101
 private-vlan isolated

!
! Community VLAN: allows a subVLAN within a Primary VLAN
!
vlan 102
 private-vlan community

!
!  Associating
!
vlan 100
 private-vlan assoc 101,102

What this step is needed for, is to group PVLANs into a domain and establish a formal association (for syntax checking and VLAN type verifications).

Step 2:

Configure host ports and bind them to the respective isolated PVLANs. Note that a host port belongs to different VLANs at the same time: downstream primary and upstream secondary.

!
! Isolated port (uses isoalated VLAN to talk to P-port)
!
interface FastEthernet x/y
 switchport mode private-vlan host
 switchport private-vlan host-association 100 101

!
! Community ports: use community VLAN
!
interface range FastEthernet x/y - z
 switchport mode private-vlan host
 switchport private-vlan host-association 100 102

Step 3:

Create a promiscuous port, and configure downstream mapping. Here we add secondary VLANs for which traffic is received by this P-port. Primary VLAN is used to send traffic downstream to all C/I ports as per their associations.

!
! Router port
!
interface FastEthernet x/y
 switchport mode private-vlan promisc
 switchport private-vlan mapping 100 add 101,102

if you need to configure an SVI on the switch, you should add an interface correspoding to Primary VLAN only. Obviously that’s because of all secondary VLANs being simply “subordiantes” of primary. In our case the config would look like this:

interface Vlan 100
 ip address 172.16.0.1 255.255.255.0

Lastly, there is another feature, worths to be mentioned, called protected port or Private VLAN edge. The feature is pretty basic and avaiable even on low-end Cisco switches, allows to isolate ports in the same VLAN. Specifically, all ports in a VLAN, marked as protected are prohibited from sending frames to each other (but still allowed to send frames to other (non-protected) ports within the same VLAN). Usually, ports configurated as protected, are also configured not to receive unknown unicast (frame with destination MAC address not in switch’s MAC table) and multicast frames flooding for added security.

Example:

interface range FastEthernet 0/1 - 2
 switchport mode access
 switchport protected
 switchport block unicast
 switchport block multicast

Tags: , , , , , , , , ,

Categories

CCIE Bloggers