Powered by Blogger.
Home » Archives for March 2013

The Mystery of Network Time Protocol

Posted by Unknown Friday, March 29, 2013 2 comments

NTP : Network Time Protocol Services on CISCO routers.

Time synchronization is very critical on CISCO routers, as without accurate date and time settings, we would not be able to generate any meaningful logs on the routers. Most of the time, all the devices on a network are in synch with famous NTP servers on the internet. All the NTP servers are in synch with some Radio or Atomic Clock. Atomic clock is the defacto standard for time keeping in the world.  Atomic clocks are also used as the primary standard for controlling television broadcast wave frequency and in global positioning systems!

If our network is not connected to the internet, we can define one or two routers/switches on our network as an NTP server. We can also create different NTP peers to create redundancy and to avoid any inaccurate tuning of time.

Some quick facts about NTP:

  • NTP uses UDP as transport protocol
  • Client/Server Protocol ( Client request time from Server)
  • All NTP communication is in UTC (Universal Coordinated Time) or GMT ( Greenwich Mean Time) Format
  • NTP Startum is the value of the number of hops an NTP server is away from Root Servers, Stratum 1 value is the best value. 


In addition to above points, we can enable NTP authentication to avoid any malicious time hack on our account. We can enable NTP authentication on the client, to authenticate the NTP server prior to synchronizing with it. I think we have enough info about NTP and good to go for a small configuration example. Once again, we are using GNS3!

NTP server and Client configuration in GNS3:

In our simple NTP demonstration, we will configure two 2691 routers, one as a Server and the other as a Client. The server router is called the Master router, or in simple words, every router try to get in synch with the Master Router on the network for time keeping. Below mentioned topology is used:


R1: Master Router/NTP Server
R2: Client Router

R1: Fast Ethernet 0/0 ( 192.168.2.1/24) / R2: Fast Ethernet 0/0 ( 192.168.2.2/24)

Just imagine, we traveled via a time machine into the future, 2020, and the task is to configure our NTP servers J

As a starting step we set clock on Master router:



As the time is set, in the next step we designate our R1 as Master by issuing ntp master command:






To confirm , all the values set on our NTP Master router, use below command:











Okay, we are good to go. Now we will configure R2 as our NTP Cleint:













And after an instant, it got synchronized with its master:











We can also check ntp associations detail via:


























The above command, confirm that the originating time and the received time are totally in synchronization.
And the time can be confirmed via simple show clock command once the whole synchronization process is done:

Cient_NTP_Router#show clock detail
13:40:46.290 UTC Wed Jan 1 2020
Time source is NTP


From the above command, it can be seen that for R2, the Time source is NTP J

NTP Authentication:

NTP Authentication is one of the major requirements in production networks, as it avoids any unwanted changed to our routers and switched time clock. It's enabled on the client, to authenticate the server before accepting it as its Master. The configuration needed on the client to enable authentication are:

Cient_NTP_Router(config)#ntp authenticate
Cient_NTP_Router(config)#ntp authentication-key 1 md5 NTPDOMAIN
Cient_NTP_Router(config)#ntp trusted-key 1
Cient_NTP_Router(config)#ntp server 192.168.2.1 key 1


We only need to define the key and md5 hash value (NTPDOMAIN) on our server, which we have defined on our client:

Master_NTP_Router(config)#ntp authentication-key 1 md5 NTPDOMAIN

And that’s it!

NTP Peers: beside the Master router, we can enable other routers as NTP peers with the client routers. NTP peers create a bidirectional sort of NTP settings, in which Peer continuously updates each other time settings. In our above GNS3 topology, we have put another router, R3, as an NTP peer with R2:

































I think, i should stop now, or for the next few weeks, you will dream about NTP!! :) Enjoy.






Which is better, G.723 or G.729 ?

Posted by Unknown Monday, March 25, 2013 0 comments


  • G.711 has a Mean Opinion Score of 4.3-4.7 and uses 80 kpbs (if you send 50 packets/second with 20 ms of RTP payload per packet) or 74.7 kbps (@ 30 ms, meaning 33.3 packets/second).
  • G.729 (NOT G.729a) has a MOS of 3.9-4.2 and uses 24 kbps @ 20 ms or 18.7 kbps @ 30 ms.
  • G.729a has a MOS of 3.7-4.2 and uses 24 kbps @ 20 ms or 18.7 kbps @ 30 ms.
  • G.723 has a MOS of 3.8-4.0 and uses 17.1 kbps @ 30 ms.


MOS is what nontechnical people think about each codec (5.0 is perfect). All of the above numbers are in EACH direction, so total bandwidth is double the above figures.

As you can see, there is very little quality or bandwidth difference betweeen G.729a and G.723. However, G.729a can send 50 packets/second, each packet containing 20 ms of voice payload. G.723's lowest setting is 30 ms. I think 20 ms sounds better than 30 ms because of smoothing (used to fill in for late packets).

It would be a very good idea to turn on silence suppression ('Silence Supp Enable' = 'yes'), because it will reduce your bandwidth usage by 65%. (Apparently each person in a two-person conversation only talks about 1/3 of the time.)

There is also the issue of transcoding. Whenever one lossy codec is decompressed and then transcoded into another lossy codec, voice quality always gets worse, so you want to avoid transcoding. I've read that G.729 is commonly used for overseas calls, so if your adapter compresses your voice using G.729 and then your long distance provider decompresses your voice and then recompresses it using G.729, no voice quality is lost. Transcoding is especially noticeable in cell-to/from-VoIP calls, so if your adapter supports GSM (SNOM does) and you choose it as your default codec, your voice quality will be better when calling GSM cell phones.

Finally, I've tried VoIP over dialup, and it's no fun, because of dial-up's high latency and jitter. It seems like there should be a Nextel-style "push to talk" adapter/software for high jitter VoIP connections (like satellite and 802.11 mesh networks), but I don't know of any. However, my test was before Sipura added the 'Network Jitter Level' = 'extremely high' setting. That setting might be enough to make a VoIP over dialup conversation workable if you're willing to take turns talking and say 'over' when you're done talking.

For more interesting discussion, please visit : http://www.dslreports.com/forum/remark,14760386


VRRP , An Overview and Implementation

Posted by Unknown 0 comments


VRRP: Virtual Router Redundancy protocol

To reach remote networks we use the following methods to discover the first hop to our remote network:
  • Dynamic process
  • Static configurations

The problem with dynamic exploration is extra network overhead, and usually static configuration is recommended as it gives the next hop detail in advance thus reducing the extra network overhead. But the problem with static next hop or in simple words default gateway configuration is redundancy as it creates a single point of failure. To overcome this, we use different redundancy configuration techniques, in which we configure a single virtual IP on a group of routers. In case one virtual gateway fails, the load is instantly shifted to the next available router according to priority. VRRP is one of those techniques as are GLBP and HSRP. In VRRP we define a Master Router and a bunch of back up routers; these backup routers are the point of redundancy in case of Master router failure. 



For example in above scenario, we have configured VRRP on all the three routers and made it a part of VRRP group 1. The mentioned virtual IP address is configured on each router. Suppose if Router A is currently active and some things abnormal happens to it, Router B or Router C will take the backup gateway place according to the priority defined for these routers in VRRP group configurations. In the same fashion we can also create different groups, with different priorities and VRRP advertisements timer values.

Quick Facts about VRRP:

  • VRRP uses 224.0.0.18 and protocol number 112
  • VRRP has virtual MAC Address 0000.5e00.01xx with xx being group number
  • VRRP default Hello interval is 1 second
  • VRRP default priority is 100
  • VRRP preemption is enabled by default 

Configuration example:

In the basic configuration of VRRP, we will cover the following topics:

  • Basic VRRP Configuration
  • VRRP priority and preempt
  • VRRP MD5 authentication
  • VRRP Packet Analysis

We are using below mentioned GNS3 topology for VRRP. It’s the same topology that we used in GLBP, but this time we are creating redundancy via VRRP.


We have created a VRRP Group 1 on R3 and R4 and have configured virtual gateway IP 192.168.1.10. The configurations are done on both router Fast Ethernet 0/0 interfaces.

VRRP Configuration done on R3 Fast Ethernet 0/0 interface is :


VRRP Configuration done on R4 Fast Ethernet 0/0 interface is:


As you can see, we have enable VRRP group 1 on R3 and R4, with clear text authentication. To verify, VRRP is in action, we can check it via show vrrp command on both routers:





From above commands output, you can see that R3 is our Master router and R4 is our backup router. Preemption is enabled on both routers by default. R3 priority is higher (120) then R4 (100). The clear text authentican password is set to cisco.

The same scenario can be used with different VRRP groups, if we want to creat multiple virtual GWs on our network for efficient load balancing and traffic handling as all hosts load on a single router can increase the work/processing load on it. VRRP is preferred routing protocol as it’s not vendor specific like GLBP. With multi-vendor interoperability, VRRP is the ultimate choice in network redundancy design.






DHCP : Dynamic Host Configuration Protocol

Posted by Unknown Saturday, March 23, 2013 0 comments


One of the many services that we mostly need in our network is DHCP. The Dynamic Host Configuration Protocol is used to dynamically assigned IP addresses and Default gateway information to the host on a network. In simple words, the DHCP functionality can be expressed as:


As can be seen, our host is acting as a DHCP client on the LAN, it will send DHCP Discover broadcast on the network, and all the relevant data will be provided like IP Address, Subnet Mask, Default Router, DNS Server, to the requesting host. DHCP discovery is a 4 leg process:

  • Discover
  • Offer
  • Request
  • Acknowledge
The client send a Discover message, the DHCP server send a Unicast Offer, the client then sends officially a Request Offer, and an ACK send by DHCP server. It seems ambiguous? Better explained by below diagram:


CISCO IOS can also be configured as a DHCP server and Client. A router can be configured as a

  • DHCP Server
  • DHCP Client
  • DHCP Proxy


Quick Facts about DHCP:

  • UDP 67 is server-side port
  • UDP 68 is client-side port


Redundancy can be created via DHCP safe fail over Protocol using a cluster of DHCP servers in which one server acts as a Primary Server and the second one act as Backup Server on which Backup address pool is configured which could be used in case of failover of the primary DHCP server. So far we have discussed the basic working of DHCP, its packet flow, and how to enable redundancy in DHCP. Now it is time to move into configuration.

Configuration:

We are going to configure DHCP in packet tracer. We have bunch of host connected to a switch, which is connected to a router. The router is acting as DHCP server and all the hosts in the network are assigned IP addresses from our defined IP pool for DHCP. The topology we will be using is as follow:




In the above network, we have enabled Routers0 interface as our DHCP and DNS server. The client are not configured with static IP, instead DHCP option is selected on each host, to get all configuration data from the DHCP server. Once the router is up and Clients are active, the client instantly updates their IP addresses and Default gateways by sending DHCP requests. We have configured a DHCP pool by name of LOCAL_LAN pool on our router; the IP addresses assigned to the hosts are leased from this IP pool. We have also mentioned some of the address which should not be assigned by the DHCP server, using
ip dhcp excluded-address , command as these addresses are already assigned or kept for future use.

The DHCP configurations done on R0 are:


The default router and dns server address is our routers Fast Ethernet 0/0 interface IP address. We have excluded the DHCP server IP and DNS IP from the list of IPs that is going to be assigned by DHCP server. To define router as proxy DHCP server, we use ip helper command under interface config mode, this just relay all DHCP requests to the mentioned DHCP server. Last thing, in dhcp options, we can also define lease time, the time duration till which the address is valid. The address will be renewed after the lease time is elapsed. 



I hope you enjoyed this article. Please do let me know your feedback and comments. 

CIDR II: A little more in depth explanation

Posted by Unknown 0 comments


PART II:

Suppose our ISP owns an address block: 200.24.0.0/16. What this means?

An address block comprises of different address that the ISP can allocate and sell to its customers. The IP address block 200.24.0.0/16 can represent 2^16 = 65, 536 IP addresses. Suppose from this block it wants to allocate 200.24.15.0/20 address block. So how many addresses is this in reality? Simple, 2^12 = 4096 or 16 /24s, how? The block size is /20 or in other words 255.255.240.0 so our block size can be calculated as 256-240 = 16 , this means the given /20 block comprises of 16 /24 addresses if we are considering a Class full environment.

200.24.15.0
200.24.16.0
200.24.17.0
200.24.18.0
200.24.19.0
200.24.20.0
200.24.21.0
200.24.22.0

200.24.23.0
200.24.24.0
200.24.25.0
200.24.26.0
200.24.27.0
200.24.28.0
200.24.29.0
200.24.30.0

Each address has the capacity to represent 255 addresses so 255*16 = 4096, as already mentioned above.  So if the ISP distributes these among 3 organizations named A, B, C—the distribution would be as follows:

200.24.15.0
200.24.16.0
200.24.17.0 Block size of 4, 256-4=252 so the whole block would be 200.24.15.0/30
200.24.18.0                    IPblock 200.24.15.0/30 will be assigned to the Organization A

200.24.19.0
200.24.20.0
200.24.21.0
200.24.22.0 Block size of 8. 256-8 = 248 so the whole block would be 200.24.19.0/21
200.24.23.0                     IPblock 200.24.19.0/21 will be assigned to organization B
200.24.24.0
200.24.25.0
200.24.26.0


200.24.27.0
200.24.28.0Block size of 4, 256-4=252, so the whole block would be 200.24.27.0/30
200.24.29.0                    IPblock 200.24.27.0/30 will be assigned to organization C
200.24.30.0

Believe me, by doing above process, we have cracked all the route aggregation and summarization at the Global, ISP and Organization level.

You will feel that CIDR has the same look like VLSM. Yes, it’s right to some extent. Both allow us to change the IP dynamics according to our requirements, but VLSM is invisible to the global internet. The VLSM can be felt only in our internal network topology. On the other side, CIDR is visible to the global internet. A global Internet Registry can assign any CIDR block or prefix block to any top level ISP, to a medium level ISP or to any private organization.

Okay now some interesting stuff. If you want to see all this CIDR, route summarization in action, visit MeritRADb the routing asset database online website. This website provides information related to all the routed networks and ASs on the internet up to this moment! For example if we want to dig this IP: 173.194.67.104, we will go to their website: http://www.ra.net/  and will query this IP using Query the RADb box. The output is quite interesting:

route:      173.194.67.0/24
descr:      Google
origin:     AS15169
notify:     radb-contact@google.com
mnt-by:     MAINT-AS15169
changed:    radb-contact@google.com 20121119
source:     RADB

This IP (173.194.67.104) is owned by Google incorporations!! Okay one more IP: 205.134.232.114

route:      205.134.224.0/19
descr:      Corporate Colocation, Inc.
origin:     AS17139
notify:     netops@mzima.net
mnt-by:     MAINT-CORPCOLO
changed:    noc@corporatecolo.com 20071108
source:     RADB

The above IP is somehow part of the major route shown in the RADb output. The Routing Asset Database website is one of a great place to spend your weekend time on!

Please remember that IANA or Internet Assigned Number Authority is the organization responsible for taking care of global IP address allocation and other IP related activities. 

CIDR - Classless Inter-domain Routing

Posted by Unknown 0 comments


PART I:

CIDR (RFC: 4632): Classless inter domain routing. In simple words, CIDR is like supernetting route summarization and VLSM at the ISP end that’s why it is called Classless inter domain routing. Confusing? Okay let us discuss it via an example; it will help us picture the whole concept. As we learned in route summarization, instead of advertising each address, a router makes a block of addresses and advertise it, it minimizes load on routers and enhances network efficiency.

Instead of assigning addresses according to the Classful subnet boundaries, the ISPs begun to assign IP addresses in the form of blocks. Then it was the duty of the ISPs to assign smaller blocks to its customers from the Big block. In CIDR the routers were given the ability to process the IP addresses according to the classless subnet prefix instead of the starting 0 and 1s in each IP address. Or in the other words, the routers were programmed to understand the prefix through which it can decide to which domain (major block of IPs) these addresses are assigned.  

If the a whole Class A, B or C address is assigned to an organization, there is a chance of the wastage of IP addresses, so IP address conservation was one of the main reasons behind CIDR development by IANA. IANA suggested assignment of IPs address ranges other than the conventional class paradigm. These policies not only helped in preserving the wastage of IP addresses but also reduced the load of the global routing tables.  So the two goals behind CIDR creation by IANA were:

  • To reduce the global routing table size
  • To preserve the IP address space

Let understand the first point via an example. Suppose we have a block of addresses are below:

192.168.20.0/24
192.168.21.0/24
192.168.22.0/24
192.168.23.0/24

We can summarize this address as:
Our block size is 4, so our best subnet choice at 3rd octet is 256-4 = 252, so we can summarize the above network IDs with following subnet IP:

192.168.20.0
255.255.252.0 OR

192.168.20.0/22

Have you noticed one interesting thing, we have moved backward from standard Class C boundary. We have an IP address 192.168.20.0 with the prefix 22 which represents a block of 4 IP addresses of 24 subnets. Now the router will only advertise with /22 addresses and the same process are repeated from our side to our ISP. Our ISP does the same route aggregation and advertises a single block to higher networks and the process goes on.  Without this process we would have millions of routing tables for the global IP traffic! And how the IP addresses are conserved? Well they are conserved when a specific block of IP addresses is assigned to customers. 

An ISP will never assign a Classful address to any corporation, as a lot of addresses will go waste and the ISP can’t take back the non-used addresses. For the solution of this problem, IP address Ownership an IP address Lending scheme was introduced but they are still in review amidst much heated debate on it.

GLBP Part II + Practical implementation

Posted by Unknown 0 comments
GLBP Configurations:


We will use GNS3 to implement GLBP. We are using two hosts with same default gateway. Our configuration check list is:
  • Basic GLBP Configuration
  • GLBP priority and preempt
  • GLBP MD5 authentication
  • GLBP Load Balancing Method
  • AVG and AVF Failover
  • GLBP Packet Analysis

We are using the following GNS3 topology:


We are using R1 and R2 to simulate our hosts in GNS3. The configuration on both these routers is:
R1(HostA)

R1#show running-config interface fastEthernet 0/0
Building configuration...

Current configuration : 96 bytes
!
interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
end

and a static route is define to point it to our default-gateway: 192.168.1.10

R1#show ip route static
S*   0.0.0.0/0 [1/0] via 192.168.1.10





Same sort of configuration is done on R2(HostB) too:

R2#show running-config interface fastEthernet 0/0
Building configuration...

Current configuration : 96 bytes
!
interface FastEthernet0/0
 ip address 192.168.1.2 255.255.255.0
 duplex auto
 speed auto
end

R2#show ip route static
S*   0.0.0.0/0 [1/0] via 192.168.1.10

R3 and R4 are our Gateways on which we will load balance the traffic and create redundancy using GLBP. Please note EIGRP is configured as routing protocol with AS # 4 on R3-R4-R5. In the next step we will enable GLBP on Fast Ethernet 0/0 interface of R3 and R4. The configuration done on each router interface is as follow:

R3#show running-config interface fastEthernet 0/0
Building configuration...

Current configuration : 283 bytes
!
interface FastEthernet0/0
 mac-address 0033.3333.3333
 ip address 192.168.1.3 255.255.255.0
 duplex auto
 speed auto
 glbp 4 ip 192.168.1.10
 glbp 4 priority 120
 glbp 4 preempt
 glbp 4 weighting 6
 glbp 4 load-balancing weighted
 glbp 4 authentication md5 key-string shah123
end

The routing configuration on R3 is as follow:

R3#show ip route eigrp
D    10.0.0.0/8 [90/409600] via 192.168.3.5, 00:09:27, FastEthernet0/1
D    192.168.2.0/24 [90/307200] via 192.168.3.5, 00:09:27, FastEthernet0/1
                    [90/307200] via 192.168.1.4, 00:09:27, FastEthernet0/0

R3#show ip route
Output ommited
Gateway of last resort is not set
D    10.0.0.0/8 [90/409600] via 192.168.3.5, 00:09:35, FastEthernet0/1
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/307200] via 192.168.3.5, 00:09:35, FastEthernet0/1
                    [90/307200] via 192.168.1.4, 00:09:35, FastEthernet0/0
C    192.168.3.0/24 is directly connected, FastEthernet0/1

As you can see GLBP group number 4 is configured on R3 with virtual gateway IP : 192.168.1.10. The priority is set to 120, as we want to make this router AVG ( Active Virtual Gateway), authentication and load balancing also adjusted. We can create various type of load balancing but here we are using weighting. The configurations on R4 are almost same, but we have given a little bit low priority number to this gateway as we would like to make it GLBP Virtual Forwarder. The configurations are as follow:

R4#show running-config interface fastEthernet 0/0
Building configuration...

Current configuration : 283 bytes
!
interface FastEthernet0/0
 mac-address 0044.4444.4444
 ip address 192.168.1.4 255.255.255.0
 duplex auto
 speed auto
 glbp 4 ip 192.168.1.10
 glbp 4 priority 110
 glbp 4 preempt
 glbp 4 weighting 7
 glbp 4 load-balancing weighted
 glbp 4 authentication md5 key-string shah123
end

R4#show ip route eigrp
D    10.0.0.0/8 [90/409600] via 192.168.2.5, 00:16:45, FastEthernet0/1
D    192.168.3.0/24 [90/307200] via 192.168.2.5, 00:16:45, FastEthernet0/1
                    [90/307200] via 192.168.1.3, 00:16:45, FastEthernet0/0

R4#show ip route
Output omitted.

Gateway of last resort is not set

D    10.0.0.0/8 [90/409600] via 192.168.2.5, 00:17:10, FastEthernet0/1
C    192.168.1.0/24 is directly connected, FastEthernet0/0
C    192.168.2.0/24 is directly connected, FastEthernet0/1
D    192.168.3.0/24 [90/307200] via 192.168.2.5, 00:17:10, FastEthernet0/1
                    [90/307200] via 192.168.1.3, 00:17:10, FastEthernet0/0

The configuration on our last router, R5, on which we will create a loop back 5 interface to test ping it from R1 and R2 to check our GLBP load balancing and redundancy, is:

R5#show ip route
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.0.0.0/24 is directly connected, Loopback5
D       10.0.0.0/8 is a summary, 00:31:59, Null0
D    192.168.1.0/24 [90/307200] via 192.168.3.3, 00:19:12, FastEthernet0/0
                    [90/307200] via 192.168.2.4, 00:19:12, FastEthernet0/1
C    192.168.2.0/24 is directly connected, FastEthernet0/1
C    192.168.3.0/24 is directly connected, FastEthernet0/0



And we are done! Now we are good to go, we can check the GLBP and verify it via the following commands:
R4#show glbp
FastEthernet0/0 - Group 4
  State is Standby
    3 state changes, last state change 00:20:20
  Virtual IP address is 192.168.1.10
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.904 secs
  Redirect time 600 sec, forwarder time-out 14400 sec
  Authentication MD5, key-string "shah123"
  Preemption enabled, min delay 0 sec
  Active is 192.168.1.3, priority 120 (expires in 8.472 sec)
  Standby is local
  Priority 110 (configured)
  Weighting 7 (configured 7), thresholds: lower 1, upper 7
  Load balancing: weighted
  Group members:
    0033.3333.3333 (192.168.1.3) authenticated
    0044.4444.4444 (192.168.1.4) local
  There are 2 forwarders (1 active)
  Forwarder 1  ---------------  >Active virtual Gatway
    State is Listen
    MAC address is 0007.b400.0401 (learnt)
    Owner ID is 0033.3333.3333
    Time to live: 14398.476 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 192.168.1.3 (primary), weighting 6 (expires in 9.976 sec)
  Forwarder 2 ----------------- > GLBP virtual Forwarder
    State is Active
      3 state changes, last state change 00:20:03
    MAC address is 0007.b400.0402 (default)
    Owner ID is 0044.4444.4444
    Preemption enabled, min delay 30 sec
    Active is local, weighting 7

And the output of the same command on R3 is as:

R3#show glbp
FastEthernet0/0 - Group 4
  State is Active
    2 state changes, last state change 00:30:01
  Virtual IP address is 192.168.1.10
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.568 secs
  Redirect time 600 sec, forwarder time-out 14400 sec
  Authentication MD5, key-string "shah123"
  Preemption enabled, min delay 0 sec
  Active is local
  Standby is 192.168.1.4, priority 110 (expires in 8.052 sec)
  Priority 120 (configured)
  Weighting 6 (configured 6), thresholds: lower 1, upper 6
  Load balancing: weighted
  Group members:
    0033.3333.3333 (192.168.1.3) local
    0044.4444.4444 (192.168.1.4) authenticated
  There are 2 forwarders (1 active)
  Forwarder 1
    State is Active
      1 state change, last state change 00:29:51
    MAC address is 0007.b400.0401 (default)
    Owner ID is 0033.3333.3333
    Redirection enabled
    Preemption enabled, min delay 30 sec
    Active is local, weighting 6
    Arp replies sent: 1
  Forwarder 2
    State is Listen
      2 state changes, last state change 00:24:42
    MAC address is 0007.b400.0402 (learnt)
    Owner ID is 0044.4444.4444
    Redirection enabled, 599.216 sec remaining (maximum 600 sec)
    Time to live: 14399.212 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 192.168.1.4 (primary), weighting 7 (expires in 9.208 sec)
    Arp replies sent: 2

to see our GLBP in action, we issue a ping from Host A ( R1) to 10.0.0.4 loopback interface on R5, arp debugging has been enabled on Host A to check GLBP in action. Here is the output:

R1#ping 10.0.0.4

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

*Mar  1 00:47:57.511: IP ARP: creating incomplete entry for IP address: 192.168.1.10 interface FastEthernet0/0
*Mar  1 00:47:57.515: IP ARP: sent req src 192.168.1.1 c001.17a4.0000,
                 dst 192.168.1.10 0000.0000.0000 FastEthernet0/0
*Mar  1 00:47:57.547: IP ARP: rcvd rep src 192.168.1.10 0007.b400.0402, dst 192.168.1.1 FastEthernet0/0.
*Mar  1 00:47:59.591: IP ARP: rcvd req src 192.168.1.4 0044.4444.4444, dst 192.168.1.1 FastEthernet0/0
*Mar  1 00:47:59.595: IP ARP: creating entry for IP address: 192.168.1.4, hw: 0044.4444.4444
*Mar  1 00:47:59.599: IP ARP: sent rep src 192.168.1.1 c001.17a4.0000,
                 dst 192.168.1.4 0044.4444.4444 FastEthernet0/0.!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 28/42/56 ms

R1#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.1.10           36   0007.b400.0402  ARPA   FastEthernet0/0

R1#traceroute 10.0.0.4

Type escape sequence to abort.
Tracing the route to 10.0.0.4

  1 192.168.1.4 28 msec 36 msec 20 msec ---- > R4 Fast Ethernet 0/0 interface for outgoing packet
  2 192.168.2.5 40 msec *  40 msec

That is great! Our new gateway has been resolved by host A while communicating with R5 loopback interface (10.0.0.4). Okay we have confirmed that our GLBP is working great virtual MAC and IP assignment is working perfectly. Now if we want to check whether redundancy is working or not, we can do the following, we will disable the Fast Ethernet 0/0 interface on R4, and check if R3 is taking its place or not:
R1#ping 10.0.0.4 repeat 2000

Type escape sequence to abort.
Sending 2000, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.....!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
Success rate is 99 percent (730/736), round-trip min/avg/max = 8/34/112

During the above highlighted instance Interface Fast Ethernet 0/0 was shut down on R4 and the traffic was shifted after a minor glitch to R3, as can be seen from below output:

R1#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.1.10            0   0007.b400.0401  ARPA   FastEthernet0/0
Internet  192.168.1.1             -   c001.17a4.0000  ARPA   FastEthernet0/0
Internet  192.168.1.3             0   0033.3333.3333  ARPA   FastEthernet0/0

As you can the virtual MAC address corresponding to Virtual GW (192.168.1.10) changed from 0007.b400.0402 ---- > 0007.b400.0401!! isn’t it great J

In short GLBP is a very good redundancy and load balancing protocol. AVG is responsible for keeping any eye on all Virtual forwarders and assigning virtual MACs according to network requirements. Active Virtual Gateway redundancy is managed by GLBP priority value and Active virtual forwarders are controlled via weight value in the configurations. 






Copyright © My CISCO Journal . All rights reserved.