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.