Project Completion

Apologies for i haven't been posting any updates for the past week.

There has been a couple of changes introduced in this last phase to cater for the demand of network performance measurements.
Throughout the week, I've made a few changes to the VLAN design and what sort of traffic type is allowed through the VPN Tunnel and which has to go through the normal MPLS Cloud.
The main idea was to send atleast 2 other traffic types apart from voice, across the GRE Tunnel interface so that we can compare the Voice latency, jitter and delay during the traffic transmission.
From the last update, the call transmission were successfully made from one network to another and tracing the path that the voice packets traverse, it was confirmed that it is running through the tunnel. Even so, with the calls be made, one can clearly identify and hear a tiny delay and voice reverb through the process of making calls which defines the voice quality expected to be giving such performance without any QoS (quality of service) configured.
Choosing Quality of Service took quite abit of days to cover since I have very little knowledge of implementing them in any network apart from a basic Lab that was available on net. Therefore, with my Supervisor's suggestion, I've managed to pick out and implement a certain QoS but wasn't sure what it would do to the network. Further discussions were made with my supervisor and after a day of reading, I've managed to implement Priority Queuing QoS. The basic idea behind priority queuing is that it classifies certain packet types that is defined to be of either in one of the 4 major packet classifications. The major classes are as follows - High, Medium, Normal and Low and one can determine what class of traffic would they want their traffic to be tagged on. Priority Queuing gives the highest priority to those packets classed "High" and then it drops down accordingly as per mentioned above. Every other traffic is treated according to it's class and if there are no High class traffic available, medium class traffic gets the highest priority.

Network Performance measurements was my next phase and that became a challenge for i have scarcely any knowledge on Traffic Generation Router (TrafGen/TGN) or Network Quality Review (NQR). After a fair bit of reading, i was able to atleast understand the core basics of how it works. Basically, TrafGen sends out a packet from one interface, gets routed through the network and then back to the TrafGen router on another interface. With the round-trip performance of the traffic generated, one will then use NQR to measure the network performance, delay-stats, jitter-stats and the summary stats of each measured packet type that was generated. We can configure and choose the type of packet that we need to measure upon traffic generation and the application port number (layer 4) that acquires network performance review. NQR also can generate its own traffic and that also was taken into account.
Evidently, when configuring Traffic generation, any other traffic types can be running simultaneously but will not be measured with the simulated generated traffic from Traffic Gen or NQR but somehow i've managed to squeeze the performance for both simulated traffic (passive and active traffic) by reducing the packet sizes but increasing the packet transmission frequency. This method causes huge delay and variation in Voice network performance which will be discussed further in the final report of this project.
List below are some traffic generation/network performance tests performed today:

Without QoS

- Run NQR

- Run NQR and TrafGen

- Run NQR and TrafGen​ + ping packets end to and and make a call end to end

With QoS configured in the Network:

- Run NQR 

- Run NQR and TrafGen

- Run NQR and TrafGen + ping packets end to and and make a call end to end

- Measure IP SLA ( No Load)

- Measure IP SLA (With Network Load: ping packets, calls end to end_

- Measure IP SLA + Load TrafGen and NQR Traffic

Finally, the last stage/phase from here is just to implement basic security features that was left to the very last stage so as to simplify network configurations.

Voip Call - Site to Site configuration

Today's project phase implementation was to configure VoIP over GRE Tunnel and enable voice through the tunnel from one end to the other (HQ to Remote Site)

After successfully configuring Voice in the internal network last Friday, 12th Sep, one was able to identify how this can also be implemented on remote site so I tried configuring the same layout from HQ into remote site. Somehow, the phone at first could not register and it only resets itself before configuring the IP details.
Before troubleshooting, i made sure that all cables were connected properly and correctly from the routers and switches at both ends to the end point interface that connects to the phone. Once all that was confirmed i used "spot-the-difference" troubleshooting method to compare the successfully working network (HQ site) configurations to the remote site configurations which wasn't able to register the IP phone when connected. I checked the DHCP configurations and made sure it was dissipating the right pool with the correct default-gateway address, checked ip-helper address and also each switchports to see if there was any difference between the 2. The default gateway on the Layer 3 switch was corrected since it was pointing back to itself but made no difference in the phone registration.
All seems properly configured. The only other reason why phones cannot receive ip addresses from the pool was because of the "option 150" command that enables each phone to find it's configuration from the assigned TFTP server in this case using the router.
Checking the dhcp pool configuration of Remote site router, it was obvious that this command was missing. I entered the command into the config file and tried connecting the phone to verify registration which then turns out to be successful.

Next in line was to try and call from HQ site to Remote site. Doing a bit of reading, i found out a basic configuration that can enable one to call from one phone to another (considering the use of ip phones) that are in different networks. Given the configuration below, i tried running them in my configuration file to see if it goes through.
!VoIP configuration from HQ to Remote - applied vice-versa
dial-peer voice 7 voip
destination-pattern 200.
session target ipv4:172.16.3.2

dial-peer voice 7 voip:  (enables one to connect to another network and make calls - 7 represents the voice tag will be used by both sites for traffic identification
destination-pattern 200.: gives you the dial plan of the other remote site, or HQ site which will be used as line ID. There is a dot (.) at the end of the last digit which basically means that all digits that comes after is acceptable and calls will be passed through as long as the first 3 digits stays the same.
session target ipv4:"ip address": the destination next hop of which is used to reach the destination network. At first i tried using the global address assigned to the serial interfaces of each end sites given 209.165.100.2 for HQ and 209.165.200.2 for remote site. I tried making calls and the calls were successfully passed through the network. Just to make sure it is going through the tunnel, i changed the target address to the end tunnel destination address of each end which was using 172.16.3.0/30 network. This also enables calls to go through the network successfully which defines traffic path going through the GRE tunnel.

Next Phase: Features implementation and network performance measurements.

Basic VOIP Configurations

After the review and recommendations given by my supervisor today, i can actually can see where i stand and what needs to be done.

All Network connectivity and pings were successfully received on either ends so i decided to move onto the next phase today, VoIP implementation.
Given a simple network platform to work on to test call settings on Cisco IP phones, i tried implementing them into the network. All configurations seems straight-forward but for some reason the phone cannot receive DHCP enabled addresses from the DHCP server.
Earlier today, i moved the DHCP configurations back to the router and have the router as my DHCP Server. The reason behind it was to have the CME configurations, DHCP and T FTP all on the same router but it doesn't really matter where the TFTP server is located due to the option 150 configuration which will point to the network that contains the IP phone configuration.
The next phase of the day was to implement VoIP. After loading all basic VoIP configurations, each phones connected to the Voice VLAN was not able to receive its destined IP address from the server. Upon discussion with my supervisor, i tried resetting the phone configs to factory-default but still no change to it.
We tried troubleshooting the entire network to find loopholes and also compare the entire performance to a simple network set-up which was working perfectly.
A few changes were made today which was considered to be loopholes:
- Changed the default-gateway on the switch to the router fa0/1 interface ip address. This was configured to be the fa0/0 on the switch which was pointing to itself. This didn't make any change for the phones still cannot receive their IP configuration from the server.
- Tried disabling HSRP and route traffic directly to the VLAN interface instead of the virtual interface. This made no difference too.
- Removed the "switchport access vlan 10" command from the switch Voice VLAN interface range. This created a change in the CME configurations which then was able to provide ip addresses and TFTP configuration, phone registration to the Cisco IP phones.

Took us over 2 hours to figure this out and as per discussion the simplest conclusion that we can make out of this is that the DHCP server was trying to delegate IP addresses to the phones but the Voice VLAN was tagged with "10" as an access port for which at some reason may have over-ride the Voice VLAN configurations and left the traffic un-tagged.  Both phones on the Voice VLAN will not incorporate un-tagged traffic and therefore will not receive IP addresses delegated by the server to access vlan 10.

Call were then enabled after all above mentioned commands were removed from the VOICE VLAN port range.

Next Phase: Configure and enable calls to be made from one network to another, configure calling features, network performance measurements.

VPN Options

Last night, i tried running Voice VLAN on IPSec using CCP and was deemed successful. All the other desired VLAN traffic performed as expected going thought NAT and only Voice VLAN went directly from HQ to Remote site sending ICMP packets directly to the internal host at each end.

Tonight, i tried Implementing IPSec into GRE Tunnel. Everything went along just as expected except that it removes the NAT at both CE Router ends and tried re-routing every individual VLAN traffic through the tunnel. This may seem right concerning security urgency but it wasn't the performance expected. The Only traffic that needs to go through the tunnel is the Voice traffic generated by Voice VLANs on both ends.

I then tried configuring GRE Tunnel manually which now works well. IPSec traffic is now running through GRE Tunnel using EIGRP 101 as is Protocol.
ICMP packets successfully traversing the network end to end.

Working on Voice Configuration and hopefully the CME features in this router allows me to implement more calling features.

VPN Traffic

After deciding to change VPN host from yesterday's project implementation phase, i tried implementing the IPSec today to be hosted from both CE Routers on either end.

Leaving the Core MPLS network to run on its forwarding state, transmitting VLAN 20, 30, 40 destined for Data, Executive and Server from HQ Site to the the remote site VLANs 60, 70 and 80 namely the same as in HQ site. This VLAN traffic is applied through NAT Translation from the CE Router at both ends, transmitted through the MPLS Core to each destined sites. VLANs 10 and 50 from each site namely Voice VLAN is to be transmitted through the VPN Tunnel.

The IPSec VPN Tunnel was configured today using CCP, tested and each VLAN was able to send ICMP traffic end to end directly to each PCs in the internal network.

Next Phase:
Implement Voice, configure and test calls, implement features, measure network performance and reporting.

MPLS VPN Configuration

Today, my task was to implement MPLS VPN configurations, Configure Voice and Allow other traffic through normal VPN. Upon further research on MPLS VPN, it was confirmed that the VPN tunnel for MPLS gets activated from the ISP's PE router (Provider's Edge Router) therefore majority of your VPN traffic gets controlled by the ISP. Some typical disadvantages are listen below:

• Your routing protocol choice might be limited.
• Your end-to-end convergence is controlled primarily by the service provider.
• The reliability of your L3 MPLS VPN is influenced by the service provider's competence level.
• Deciding to use MPLS VPN services from a particular service provider also creates a very significant lock-in. It’s hard to change the provider when it’s operating your network core.

Considering security, i'd prefer having the core Control of my traffic In-house therefore every other traffic will now continue to run through the core MPLS Switching path except Voice which will be routed from CE Router (Customer Edge Router) to the end destination.

It took a while to try and figure out the basic principles of MPLS VPN and its configurations and then trying to apply them to the main-project implementation frame. After the above mentioned finding, i will now have to change the VPN plan to traffigate Voice traffic from the CE router on each ends instead of passing it through the MPLS Core.

Next Phase: 

- Configure Voice calls site to site and within sites

- Apply voice traffic through VPN (configure VPN using CCP)

- Test voice-quality scoring and performance

Ref:

(Retrieved from:  http://searchenterprisewan.techtarget.com/guides/MPLS-VPN-fundamentals, Open at 7:30pm, Sunday - 7th September, 2014)

VLAN Configuration

VLAN administration is always a challenging bit in my networking carrier and today's task invloves the following:

- Create 4 Different VLANS namely Voice, Data, Executive and Server

- create an access-list allowing all other vlans except Voice which is to be transported via VPN

- Create a dynamic and static Global pool for NAT translations

- test connectivity from HQ to Remote site using the translation pool of addresses.

All vlans were successfully created and were able to route icmp traffic from one to another. A challenge was met when HQ was able to ping successfully to the Remote site including it's translated address whereas Remote Site couldn't ping back.

Troubleshooting this problem using comparison and shoot from the hip method.Took quite a while to finally figure out the phase that created the drop in ICMP packets from Remote to HQ site.

After troubleshooting, one can successfully ping the translated address both ways from either site.

With MPLS Core and VLANs all functioning accordingly, the next phase of implementation is to configure Voice into the provided network.

MPLS Update

Managed to get run MPLS today in my core network. Made a few show commands for basic analysis and will be implementing MPLS Core Switching configurations in the week to come.

Anway, was abit stuck today when i tried running vlan configurations for voice. Once that is fixed, should be able to implement voice and traffic tests will be up soon.

Do find below some show command results and a tickle script after implementing MPLS.

PE-HQ#traceroute 209.165.200.225

Type escape sequence to abort.
Tracing the route to 209.165.200.225

  1 10.10.10.2 [MPLS: Label 21 Exp 0] 60 msec 60 msec 60 msec
  2 10.10.20.1 [MPLS: Label 21 Exp 0] 52 msec 48 msec 48 msec
  3 209.165.200.2 24 msec 20 msec 24 msec
  4 209.165.200.225 20 msec 20 msec 24 msec



P-ISPSW#traceroute 209.165.100.225

Type escape sequence to abort.
Tracing the route to 209.165.100.225

  1 10.10.10.1 [MPLS: Label 21 Exp 0] 12 msec 12 msec 16 msec
  2 209.165.100.2 16 msec 12 msec 16 msec
  3 209.165.100.225 16 msec 16 msec 12 msec


P-ISPSW#traceroute 209.165.200.225

Type escape sequence to abort.
Tracing the route to 209.165.200.225

  1 10.10.20.1 [MPLS: Label 21 Exp 0] 36 msec 36 msec 36 msec
  2 209.165.200.2 16 msec 12 msec 16 msec
  3 209.165.200.225 16 msec 12 msec 12 msec


PE-REMOTE#traceroute 209.165.100.225

Type escape sequence to abort.
Tracing the route to 209.165.100.225

  1 10.10.20.2 [MPLS: Label 19 Exp 0] 60 msec 60 msec 60 msec
  2 10.10.10.1 [MPLS: Label 21 Exp 0] 28 msec 28 msec 28 msec
  3 209.165.100.2 24 msec 20 msec 20 msec
  4 209.165.100.225 20 msec 20 msec 24 msec



PE-HQ SHOW COMMANDS

PE-HQ#show mpls int
PE-HQ#show mpls interfaces
Interface              IP            Tunnel   Operational
Serial0/0/1            Yes (ldp)     No       Yes
PE-HQ#
PE-HQ#


PE-HQ#show mpls ldp discovery
 Local LDP Identifier:
    10.2.1.1:0
    Discovery Sources:
    Interfaces:
        Serial0/0/1 (ldp): xmit/recv
            LDP Id: 10.1.1.1:0; no host route


PE-HQ#show mpls ldp nei
PE-HQ#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.1:0; Local LDP Ident 10.2.1.1:0
        TCP connection: 10.1.1.1.646 - 10.2.1.1.24613
        State: Oper; Msgs sent/rcvd: 30/30; Downstream
        Up time: 00:16:14
        LDP discovery sources:
          Serial0/0/1, Src IP addr: 10.10.10.2
        Addresses bound to peer LDP Ident:
          10.10.10.2      10.10.20.2      10.1.1.1


PE-HQ#show mpls ldp bin
PE-HQ#show mpls ldp bindings
  tib entry: 10.1.1.0/24, rev 12
        local binding:  tag: 19
        remote binding: tsr: 10.1.1.1:0, tag: imp-null
  tib entry: 10.2.1.0/24, rev 8
        local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.1:0, tag: 16
  tib entry: 10.3.1.0/24, rev 6
        local binding:  tag: 18
        remote binding: tsr: 10.1.1.1:0, tag: 17
  tib entry: 10.10.10.0/30, rev 10
        local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.1:0, tag: imp-null
  tib entry: 10.10.20.0/30, rev 14
        local binding:  tag: 20
        remote binding: tsr: 10.1.1.1:0, tag: imp-null
  tib entry: 209.165.100.0/30, rev 16
        local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.1:0, tag: 18
  tib entry: 209.165.100.224/27, rev 18
        local binding:  tag: 21
        remote binding: tsr: 10.1.1.1:0, tag: 19
  tib entry: 209.165.200.0/30, rev 4
        local binding:  tag: 17
        remote binding: tsr: 10.1.1.1:0, tag: 20
  tib entry: 209.165.200.224/27, rev 2
        local binding:  tag: 16
        remote binding: tsr: 10.1.1.1:0, tag: 21



P-ISPSW SHOW COMMANDS

P-ISPSW#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
Serial0/0/0            Yes (ldp)     No       No  No     Yes
Serial0/0/1            Yes (ldp)     No       No  No     Yes
P-ISPSW#
P-ISPSW#
P-ISPSW#show mpls ldp di
P-ISPSW#show mpls ldp discovery
 Local LDP Identifier:
    10.1.1.1:0
    Discovery Sources:
    Interfaces:
        Serial0/0/0 (ldp): xmit/recv
            LDP Id: 10.2.1.1:0; no host route
        Serial0/0/1 (ldp): xmit/recv
            LDP Id: 10.3.1.1:0; no host route
P-ISPSW#
P-ISPSW#
P-ISPSW#show mpls ldp nei
P-ISPSW#show mpls ldp neighbor
    Peer LDP Ident: 10.3.1.1:0; Local LDP Ident 10.1.1.1:0
        TCP connection: 10.3.1.1.29031 - 10.1.1.1.646
        State: Oper; Msgs sent/rcvd: 36/36; Downstream
        Up time: 00:21:19
        LDP discovery sources:
          Serial0/0/1, Src IP addr: 10.10.20.1
        Addresses bound to peer LDP Ident:
          10.10.20.1      209.165.200.1   10.3.1.1
    Peer LDP Ident: 10.2.1.1:0; Local LDP Ident 10.1.1.1:0
        TCP connection: 10.2.1.1.24613 - 10.1.1.1.646
        State: Oper; Msgs sent/rcvd: 35/35; Downstream
        Up time: 00:20:44
        LDP discovery sources:
          Serial0/0/0, Src IP addr: 10.10.10.1
        Addresses bound to peer LDP Ident:
          209.165.100.1   10.10.10.1      10.2.1.1
P-ISPSW#
P-ISPSW#
P-ISPSW#show mpls ldp bind
P-ISPSW#show mpls ldp bindings
  lib entry: 10.1.1.0/24, rev 2
        local binding:  label: imp-null
        remote binding: lsr: 10.3.1.1:0, label: 16
        remote binding: lsr: 10.2.1.1:0, label: 19
  lib entry: 10.2.1.0/24, rev 4
        local binding:  label: 16
        remote binding: lsr: 10.3.1.1:0, label: 17
        remote binding: lsr: 10.2.1.1:0, label: imp-null
  lib entry: 10.3.1.0/24, rev 6
        local binding:  label: 17
        remote binding: lsr: 10.3.1.1:0, label: imp-null
        remote binding: lsr: 10.2.1.1:0, label: 18
  lib entry: 10.10.10.0/30, rev 8
        local binding:  label: imp-null
        remote binding: lsr: 10.3.1.1:0, label: 18
        remote binding: lsr: 10.2.1.1:0, label: imp-null
  lib entry: 10.10.20.0/30, rev 10
        local binding:  label: imp-null
        remote binding: lsr: 10.3.1.1:0, label: imp-null
        remote binding: lsr: 10.2.1.1:0, label: 20
  lib entry: 209.165.100.0/30, rev 12
        local binding:  label: 18
        remote binding: lsr: 10.3.1.1:0, label: 19
        remote binding: lsr: 10.2.1.1:0, label: imp-null
  lib entry: 209.165.100.224/27, rev 14
        local binding:  label: 19
        remote binding: lsr: 10.3.1.1:0, label: 20
        remote binding: lsr: 10.2.1.1:0, label: 21
  lib entry: 209.165.200.0/30, rev 16
        local binding:  label: 20
        remote binding: lsr: 10.3.1.1:0, label: imp-null
        remote binding: lsr: 10.2.1.1:0, label: 17
  lib entry: 209.165.200.224/27, rev 18
        local binding:  label: 21
        remote binding: lsr: 10.3.1.1:0, label: 21
        remote binding: lsr: 10.2.1.1:0, label: 16




PE-REMOTE SHOW COMMANDS

PE-REMOTE#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
Serial0/0/0            Yes (ldp)     No       No  No     Yes
PE-REMOTE#
PE-REMOTE#
PE-REMOTE#
PE-REMOTE#show mpls ldp dis
PE-REMOTE#show mpls ldp discovery
 Local LDP Identifier:
    10.3.1.1:0
    Discovery Sources:
    Interfaces:
        Serial0/0/0 (ldp): xmit/recv
            LDP Id: 10.1.1.1:0; no host route
PE-REMOTE#
PE-REMOTE#
PE-REMOTE#
PE-REMOTE#show mpls ldp nei
PE-REMOTE#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.1:0; Local LDP Ident 10.3.1.1:0
        TCP connection: 10.1.1.1.646 - 10.3.1.1.29031
        State: Oper; Msgs sent/rcvd: 40/40; Downstream
        Up time: 00:24:30
        LDP discovery sources:
          Serial0/0/0, Src IP addr: 10.10.20.2
        Addresses bound to peer LDP Ident:
          10.10.10.2      10.10.20.2      10.1.1.1
PE-REMOTE#
PE-REMOTE#
PE-REMOTE#
PE-REMOTE#show mpls ldp bind
PE-REMOTE#show mpls ldp bindings
  lib entry: 10.1.1.0/24, rev 2
        local binding:  label: 16
        remote binding: lsr: 10.1.1.1:0, label: imp-null
        remote binding: lsr: 10.1.1.1:0, label: imp-null
        local binding:  label: 17
        remote binding: lsr: 10.1.1.1:0, label: 16
  lib entry: 10.3.1.0/24, rev 6
        local binding:  label: imp-null
        remote binding: lsr: 10.1.1.1:0, label: 17
  lib entry: 10.10.10.0/30, rev 8
        local binding:  label: 18
        remote binding: lsr: 10.1.1.1:0, label: imp-null
  lib entry: 10.10.20.0/30, rev 10
        local binding:  label: imp-null
        remote binding: lsr: 10.1.1.1:0, label: imp-null
  lib entry: 209.165.100.0/30, rev 12
        local binding:  label: 19
        remote binding: lsr: 10.1.1.1:0, label: 18
  lib entry: 209.165.100.224/27, rev 14
        local binding:  label: 20
        remote binding: lsr: 10.1.1.1:0, label: 19
  lib entry: 209.165.200.0/30, rev 16
        local binding:  label: imp-null
        remote binding: lsr: 10.1.1.1:0, label: 20
  lib entry: 209.165.200.224/27, rev 18
        local binding:  label: 21
        remote binding: lsr: 10.1.1.1:0, label: 21


TCLSH SCRIPT

HQ to REMOTE

foreach address {
209.165.100.2
209.165.100.1
10.10.10.1
10.10.10.2
10.10.20.1
10.10.20.2
209.165.200.1
209.165.200.2
209.165.200.225
} {
ping $address
}





RESULTS

CE-HQ#tclsh
CE-HQ(tcl)#foreach address {
+>172.16.1.1
+>209.165.100.2
+>209.165.100.1
+>10.10.10.1
+>10.10.10.2
+>10.10.20.1
+>10.10.20.2
+>209.165.200.1
+>209.165.200.2
+>209.165.200.225
+>} {
+>ping $address
+>}

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.165.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/36 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.165.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/16 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/16 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/28/32 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/42/44 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.20.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/29/32 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.165.200.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/44/48 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.165.200.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.165.200.225, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/60 ms
CE-HQ(tcl)#

Current Update - End to End Solution

For a week to date, i've been trying to figure out how to make connectivity from the HQ's internal network to the Remote site's internal network. With Mark's help, we were able to troubleshoot and find a few loop holes that prevents end to end connectivity. A pool of addresses were created for both internal networks (172.16.1.0/24 - HQ and 172.16.2.0/24 - REMOTE) and given the Public pool distribution by the TELCO Provider (209.165.200.224 for remote and 209.165.100.224 for HQ) respectively. Dynamic NAT translation was configured for the 2 pools and with a given internal ip address from each end, a static NAT was also configured to provide end to end translation and provide entry to each respective internal network via the ISP or TELCO Provider.

With abit of complications met, a few troubleshooting methods were introduced - shoot from the hip and follow the path method were used in this case given the following show commands:

- show ip route, show nat translations, show nat statistics and traceroute.

The traceroute command show potential problem within the internal network that prevents end to end connectivity. Disabling the PC firewall enable the ICMP packets to be received.

Given below are the connectivity test results in TCL script form.

HQ to REMOTE

foreach address {

209.165.100.2

209.165.100.1

10.10.10.1

10.10.10.2

10.10.20.1

10.10.20.2

209.165.200.1

209.165.200.2

209.165.200.225

} {

ping $address 

}

RESULTS

CE-HQ#tclsh

CE-HQ(tcl)#foreach address {

+>172.16.1.1

+>209.165.100.2

+>209.165.100.1

+>10.10.10.1

+>10.10.10.2

+>10.10.20.1

+>10.10.20.2

+>209.165.200.1

+>209.165.200.2

+>209.165.200.225

+>} {

+>ping $address

+>}

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 209.165.100.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/36 ms

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 209.165.100.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/16 ms

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/16 ms

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/28/32 ms

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.20.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 40/42/44 ms

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.20.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/29/32 ms

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 209.165.200.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 40/44/48 ms

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 209.165.200.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 209.165.200.225, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/60 ms

CE-HQ(tcl)#

The next phase is to implement MPLS into this network and see if it is capable of handling MPLS traffic.

Basic Connectivity configurations

Project Implementation is underway and am currently working on the basic network connectivity. Current issues faced at the moment is the NAT translation that requires Public to Private address translation. The ICMP packets doesn't seem to pick the virtual Public address from each ends of the Customer Link (HQ - Remote CE)

Current protocols running within the network are BGP and OPSPF - with static routing and default routes applied to interfaces where it suites.

Current investigation is underway to troubleshoot the problem at hand and hoping to discuss this with Mark (Lecturer) sometimes this week.

Apart from those complications, DHCP, running protocols and basic internal connectivity is performing as expected.

The next four phases of this project implementation are:
1. Apply MPLS Core Switching configurations

2. Implement IP-PBX

3. Configure CME Features

4. Network Performance testing

Basic complete rate is targeted to end of mid-semester 2.

MPLS and Voice Intergration

MPLS Design for VoIP – Protocol Integration

Time sensitive traffic such as voice and video are forwarded in UDP which operates on the “Send and Pray” transmission philosophy whereby there is no such mechanism to detect or recover from lost or errored packets. In short, you’ve got only one shot at delivering a voice packet so a network that guarantees performance for delay, jitter and loss has a far greater value in supporting voice and video services.

Building an MPLS based Converged Network

With any guaranteed packet service such as Frame Relay, there are two critical transmission rates: the access rate and the service's guaranteed capacity. An access rate transmission is often linked to the Committed Information Rate (CIR) of any Link. As long as the average transmission stays below the CIR, the carrier guarantees to deliver a very high percentage of traffic typically 99.99%. If the transmission rate on that virtual circuit exceeds the CIR then the over-lapping traffic is marked as Discard Eligible and will only be delivered if there is capacity available. These discard eligible packets are usually discarded when there is congestion condition.

These concepts have been adopted in MPLS however it has had to be modified in two important ways given the nature of the MPLS Technology:

1.       Where Frame-Relay essentially offers 2 traffic categories, guaranteed and discard eligible, an MPLS Network can offer 3 or more; for convenience those categories are often called Gold, Silver, Bronze and Best Effort. The Carrier provides different guarantees regarding delay, jitter and packet loss for traffic sent in each category.

2.       The introduction of CoS (Class of Service) instead of CIR in contrast to Frame-Relay networks. Such traffic classification gives an edge on certain percentage of access capacity which is allocated according to traffic category. The class of service profile is priced proportionally to the value of service it operates on. Therefore the Higher the class, the more cost it generates. In this project, such classification is essential and will have voice traffic as the highest priority assigned. Unless we have other simultaneous running application, we may not really need such classification in the project.

How is Voice Traffic Treated in MPLS

Most Network Engineers have not had to deal with the design of voice networks using MPLS. Taking a closer look at how MPLS actually works, we do find that there are just 2 main categories:

1.       Real Time

2.       Everything Else

The important difference is how the traffic is treated between real-time and every other traffic types. It is quite important to consider the classification of traffic especially if it is treated with high priority. We all know that IP Voice uses UDP Protocol thus having one chance to transmit traffic without following up error or corrupted packets along transmission. To minimize errors or packet loss, different voice encoding modulation systems are used to compress voice quality thus giving efficient use of capacity and less packet loss tolerance.

We must make sure that Voice traffic and its classifications are set with the highest priority due to real-time traffic class demand. With such configuration (Gold Platform class) we must not configure too much of voice channels over what the class platform can contain. Attempting this will only result in packet loss: eg; If you try to configure 10 voice channels over a service with a Gold capacity that can cater for just 5; you will not have 5 good voice trunks and 5 bad ones, you will have 10 bad trunks altogether.

Thus, it is rather highly recommended that each class if well defined accordingly to the traffic types it will transmit and well within the scope of class capacity that it is transmitted on.

Ref: Michael F. Finneran, "MPLS Design for VoIP - What every user needs to know", July, 1006

  

Basic VoIP Configurations - Auto QoS Implemetation.

Basic Switch QoS Application Configurations

Step 1
. Ensure that QoS is globally enabled with the command
mls qos and enter the configuration mode for the interface on which you want to configure Voice VLANs.

Step 2.
Enable the voice VLAN on the switch port and associate a VLAN ID using the interface command switchport voice vlan
vlan-id.

Step 3.
Configure the port to trust CoS or trust DSCP as frames arrive on the switch port using the mls qos trust cosor mls qos trust
dscp commands, respectively. Recall that the mls qos trust cos command directs the switch to trust ingress CoS values whereas
mls qos trust dscp trusts ingress DSCP values. Do not confuse the two commands as each configures the switch
to look at different bits in the frame for classification.


Note: Configuring auto QoS on an interface automatically adds global mls qos srr-queue, class map and policy-map commands
to the running configuration. A number of interface-specific command are also added, including spanning-tree protfast
  - command: mls qos
int range fa0/7-12
auto qos voip trust



DLS1 (Switch 1)


hostname DLS1
int vlan 1
ip address 172.16.1.3 255.255.255.0
no shut


int range fa0/7-8
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode active

int range fa0/9-10
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode active

int range fa0/11-12
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 3 mode active


vtp domain SWPOD
vtp version 2
vlan 10
name CD-DATA
exit
vlan 20
name VOICE
exit
vlan 30
name VIDEO


ip routing
int vlan 1
standby 1 ip 172.16.1.1
standby 1 preempt
standby 1 priority 150
exit
int vlan 10
ip address 172.16.10.3 255.255.255.0
standby 1 ip 172.16.10.1
standby 1 preempt
standby 1 priority 150
exit
int vlan 20
ip address 172.16.20.3 255.255.255.0
standby 1 ip 172.16.20.1
standby 1 preempt
standby 1 priority 100
exit
int vlan 30
ip address 172.16.30.3 255.255.255.0
standby 1 ip 172.16.30.1
standby 1 preempt
standby 1 priority 100
exit


mls qos
int range fa0/7-12
auto qos voip trust







DLS2 (Switch 2)

hostname DLS2
int vlan 1
ip address 172.16.1.4 255.255.255.0
no shut


int range fa0/7-8
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode active

int range fa0/9-10
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 2 mode active

int range fa0/11-12
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 3 mode active


ip routing
int vlan 1
standby 1 ip 172.16.1.1
standby 1 preempt
standby 1 priority 100
exit
int vlan 10
ip address 172.16.10.4 255.255.255.0
standby 1 ip 172.16.10.1
standby 1 preempt
standby 1 priority 100
exit
int vlan 20
ip address 172.16.20.4 255.255.255.0
standby 1 ip 172.16.20.1
standby 1 preempt
standby 1 priority 150
exit
int vlan 30
ip address 172.16.30.4 255.255.255.0
standby 1 ip 172.16.30.1
standby 1 preempt
standby 1 priority 150
exit


mls qos
int range fa0/7-12
auto qos voip trust







ALS1 (Switch 3)

hostname ALS1
int vlan 1
ip address 172.16.1.101 255.255.255.0
no shut
exit
ip default-gateway 172.16.1.1

int range fa0/7-8
switchport mode trunk
channel-group 1 mode active

int range fa0/9-10
switchport mode trunk
channel-group 2 mode active

int range fa0/11-12
switchport mode trunk
channel-group 3 mode active



vtp domain client


int range fa0/15-24
switchport mode access
switchport access vlan 10
switchport voice vlan 20
auto qos voip cisco-phone






ALS2 (Switch 4)

hostname ALS2
int vlan 1
ip address 172.16.1.102 255.255.255.0
no shut
exit
ip default-gateway 172.16.1.1

int range fa0/7-8
switchport mode trunk
channel-group 1 mode active

int range fa0/9-10
switchport mode trunk
channel-group 2 mode active

int range fa0/11-12
switchport mode trunk
channel-group 3 mode active


vtp domain client


int range fa0/15-24
switchport mode access
switchport access vlan 10
switchport voice vlan 20
auto qos voip cisco-phone


int fa0/5
switchport mode access
switchport access vlan 30
mls qos trust cos
mls qos cos 3


This is based on CCNP Switch Lab 7.2 0 Voice Implementation Network.

MPLS Basic Config File

Hi Mark,
I know this post is long over-due :)

This is just a basic MPLS Network configuration that's yet to be developed but has helped me unerstand the basic MPLS operations.

Basic MPLS Configuration Lab

Config File

Router R1

config t
hostname LSR1
interface L0
ip address 172.16.1.1 255.255.255.0
interface fa0/0
ip address 172.16.12.1 255.255.255.0
no shutdown
exit
!
router eigrp 1
no auto-summary
network 172.16.0.0
!
interface fa0/0
mpls ip
exit
end



Router R2

config t
hostname LSR2
interface L0
ip address 172.16.2.1 255.255.255.0
interface fa0/0
ip address 172.16.12.2 255.255.255.0
no shutdown
!
interface serial 0/0/1
ip address 172.16.23.2 255.255.255.0
clockrate 64000
no shutdown
exit
!
router eigrp 1
no auto-summary
network 172.16.0.0
!
interface fa0/0
mpls ip
exit
int s0/0/1
mpls ip
exit
end


Router R3

config t
hostname LSR3
interface L0
ip address 172.16.3.1 255.255.255.0
interface serial 0/0/0
ip address 172.16.23.3 255.255.255.0
no shutdown
exit
!
router eigrp 1
no auto-summary
network 172.16.0.0
!
interface fa0/0
mpls ip
exit
int s0/0/0
mpls ip
exit
end






1. Connectivity Tests:

foreach address {

172.16.12.2
172.16.2.1
172.16.23.2
172.16.23.3
172.16.3.1
172.16.1.1
} {
ping $address
}

Result:

ype escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/28/32 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/33/48 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
LSR1(tcl)#


2. Trace Route:

LSR1#traceroute 172.16.3.1

Type escape sequence to abort.
Tracing the route to 172.16.3.1

  1 172.16.12.2 [MPLS: Label 16 Exp 0] 44 msec 44 msec 48 msec
  2 172.16.23.3 12 msec 12 msec *
LSR1#

Show Commands:

a). show ip route: provides you with the network routing table

LSR1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 5 subnets
D       172.16.23.0 [90/20514560] via 172.16.12.2, 00:01:40, FastEthernet0/0
C       172.16.12.0 is directly connected, FastEthernet0/0
C       172.16.1.0 is directly connected, Loopback0
D       172.16.2.0 [90/156160] via 172.16.12.2, 00:01:40, FastEthernet0/0
D       172.16.3.0 [90/20642560] via 172.16.12.2, 00:01:40, FastEthernet0/0



b). show mpls interfaces (R1, R2, R3): view a quick summary of interfaces configured with MPLS (command based on mpls ip)

LSR1#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/0        Yes (ldp)     No       No  No     Yes
LSR1#
LSR2#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/0        Yes (ldp)     No       No  No     Yes
Serial0/0/1            Yes (ldp)     No       No  No     Yes
LSR2#
LSR3#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/0        Yes           No       No  No     No
Serial0/0/0            Yes (ldp)     No       No  No     Yes
LSR3#



c). show mpls idp discovery: to find out local sources for LDP exchanges

LSR3#show mpls ldp discovery
 Local LDP Identifier:
    172.16.3.1:0
    Discovery Sources:
    Interfaces:
        Serial0/0/0 (ldp): xmit/recv
            LDP Id: 172.16.2.1:0; no host route
LSR3#
LSR2#show mpls ldp discovery
 Local LDP Identifier:
    172.16.2.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet0/0 (ldp): xmit/recv
            LDP Id: 172.16.1.1:0; no host route
        Serial0/0/1 (ldp): xmit/recv
            LDP Id: 172.16.3.1:0; no host route
LSR2#
LSR1#show mpls ldp discovery
 Local LDP Identifier:
    172.16.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet0/0 (ldp): xmit/recv
            LDP Id: 172.16.2.1:0; no host route
LSR1#


d). show mpls ldp neighbor: shows ldp adjacencies

LSR1#show mpls ldp nei
    Peer LDP Ident: 172.16.2.1:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.2.1.60587 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 19/19; Downstream
        Up time: 00:10:25
        LDP discovery sources:
          FastEthernet0/0, Src IP addr: 172.16.12.2
        Addresses bound to peer LDP Ident:
          172.16.12.2     172.16.2.1      172.16.23.2
LSR1#
LSR2#show mpls ldp nei
    Peer LDP Ident: 172.16.1.1:0; Local LDP Ident 172.16.2.1:0
        TCP connection: 172.16.1.1.646 - 172.16.2.1.60587
        State: Oper; Msgs sent/rcvd: 20/20; Downstream
        Up time: 00:10:49
        LDP discovery sources:
          FastEthernet0/0, Src IP addr: 172.16.12.1
        Addresses bound to peer LDP Ident:
          172.16.12.1     172.16.1.1
    Peer LDP Ident: 172.16.3.1:0; Local LDP Ident 172.16.2.1:0
        TCP connection: 172.16.3.1.37941 - 172.16.2.1.646
        State: Oper; Msgs sent/rcvd: 15/15; Downstream
        Up time: 00:06:06
        LDP discovery sources:
          Serial0/0/1, Src IP addr: 172.16.23.3
        Addresses bound to peer LDP Ident:
          172.16.23.3     172.16.3.1
LSR2#
LSR3#show mpls ldp nei
    Peer LDP Ident: 172.16.2.1:0; Local LDP Ident 172.16.3.1:0
        TCP connection: 172.16.2.1.646 - 172.16.3.1.37941
        State: Oper; Msgs sent/rcvd: 15/15; Downstream
        Up time: 00:06:21
        LDP discovery sources:
          Serial0/0/0, Src IP addr: 172.16.23.2
        Addresses bound to peer LDP Ident:
          172.16.12.2     172.16.2.1      172.16.23.2
LSR3#



e). show mpls ldp bindings: displays Label Information Base

LSR1#show mpls ldp binding
  lib entry: 172.16.1.0/24, rev 2
        local binding:  label: imp-null
        remote binding: lsr: 172.16.2.1:0, label: 17
  lib entry: 172.16.2.0/24, rev 6
        local binding:  label: 16
        remote binding: lsr: 172.16.2.1:0, label: imp-null
  lib entry: 172.16.3.0/24, rev 10
        local binding:  label: 18
        remote binding: lsr: 172.16.2.1:0, label: 16
  lib entry: 172.16.12.0/24, rev 4
        local binding:  label: imp-null
        remote binding: lsr: 172.16.2.1:0, label: imp-null
  lib entry: 172.16.23.0/24, rev 8
        local binding:  label: 17
        remote binding: lsr: 172.16.2.1:0, label: imp-null

LSR2#show mpls ldp binding
  lib entry: 172.16.1.0/24, rev 10
        local binding:  label: 17
        remote binding: lsr: 172.16.1.1:0, label: imp-null
        remote binding: lsr: 172.16.3.1:0, label: 16
  lib entry: 172.16.2.0/24, rev 2
        local binding:  label: imp-null
        remote binding: lsr: 172.16.1.1:0, label: 16
        remote binding: lsr: 172.16.3.1:0, label: 17
  lib entry: 172.16.3.0/24, rev 8
        local binding:  label: 16
        remote binding: lsr: 172.16.1.1:0, label: 18
        remote binding: lsr: 172.16.3.1:0, label: imp-null
  lib entry: 172.16.12.0/24, rev 4
        local binding:  label: imp-null
        remote binding: lsr: 172.16.1.1:0, label: imp-null
        remote binding: lsr: 172.16.3.1:0, label: 18
  lib entry: 172.16.23.0/24, rev 6
        local binding:  label: imp-null
        remote binding: lsr: 172.16.1.1:0, label: 17
        remote binding: lsr: 172.16.3.1:0, label: imp-null

LSR3#show mpls ldp binding
  lib entry: 172.16.1.0/24, rev 2
        local binding:  label: 16
        remote binding: lsr: 172.16.2.1:0, label: 17
  lib entry: 172.16.2.0/24, rev 4
        local binding:  label: 17
        remote binding: lsr: 172.16.2.1:0, label: imp-null
  lib entry: 172.16.3.0/24, rev 6
        local binding:  label: imp-null
        remote binding: lsr: 172.16.2.1:0, label: 16
  lib entry: 172.16.12.0/24, rev 8
        local binding:  label: 18
        remote binding: lsr: 172.16.2.1:0, label: imp-null
  lib entry: 172.16.23.0/24, rev 10
        local binding:  label: imp-null
        remote binding: lsr: 172.16.2.1:0, label: imp-null

Project Time-Schedule

Project Plan - Voice over MPLS (2014)
Outcomes		March 2014	April 2014	May 2014	June 2014	July 2014	Aug 2014	Sep 2014	Oct 2014	Nov 2014	Total (Hrs)
1	Initial negotiation (i.e. understanding the problem and requirements). (Hrs.)	(20) 03/03 – 15/03									20
	Actual hours	15									15
2	Initial plan, budget & proposal submission (hrs.)	( 12) 17/03 – 28/03	(12 ) 01/04 – 14/04								24
	Actual hours	12	12								24
3	Client meetings (hrs.)	4	2	4	4	4	4	4	4		30
	Actual hours	2									2
4	MPLS/VoIP research, MPLS Lab		(48) 01/04 – 30/04								48
	Actual hours
5	VoIP configuration tests, result analysis			(48) 01/05 – 31/05							48
	Actual hours
6	MPLS configuration tests, result analysis progress report				(48) 01/06 – 30/06						48
	Actual hours
7	Protocol integration research, lab simulation , result analysis					(48) 01/07 – 31/07					48
	Actual hours
8	Network measurements, basic security implementation						(48) 01/08 – 31/08				48
	Actual hours
10	Feature implementation, network capacity test, result analysis							(48) 01/09 – 31/09			48
	Actual hours
11	Test results and analysis, Final report draft							(24) 01/09 (Start)	(24) 15/10 (End)		48
	Actual hours
12	Final presentation, P&L/project Report submission								(48) 01/10 – 30/10		48
12	Total Budget Hours ()	36	62	52	52	52	52	76	76		(458)