No Voicemailbox association on CUE
I’ve recently encountered an issue on CUE as it pertains to user mailboxes. Whenever someone tried to leave a message for a particular user, they were told by the AutoAttendant that there was no mailbox associated with the user’s extension. Before we go any further, let’s get some more information on how the environment is currently setup.
CME is configured to use SIP Trunking back to the ISP in order to make calls. Each user has Direct Inward Dial (DID) extensions. Here’s a sample config of what the Ephone-DN on CME and the Voicemailbox on CUE looks like.
CME Ephone-DN config for Userephone-dn 1 dual-linenumber 7890 secondary 1234567890 no-reg bothlabel Johndescription 123-456-7890name John Doecall-forward busy 1000call-forward noan 1000 timeout 20
CUE config for Userusername John create
username John phonenumber “7890”
voicemail mailbox owner “John” size 1772description “John mailbox”end mailbox
voicemail notification owner John enable
Reviewing the configuration above you would think that your voicemail mailbox configuration for this user is correct, right? Wrong! If you placed a call to this user from an internal phone to their primary extension of 1234, you’d be able to leave a message however, if an external user placed a call to the DID number of 1234567890, they would be told that there is no mailbox associated with the number. The reason for this, is that when an external user places a call to the DID number, the AutoAttendant forwards the entire DID number and tries to find a mailbox associated with this number. Because the primary number associated with the mailbox is 7890 and not 1234567890, the mailbox lookup fails. To correct this issue we would need to change the phone number associated with the mailbox in CUE to the DID number of 1234567890.
username John phonenumber “1234567890”
I was able to verify this by enabling call forwarding to voicemail on the user’s phone, enabling the “debug voice dialpeer” command and then placing a call to that user’s DID number.
CCSA/E Study Notes – Advanced Upgrading
Checkpoint provides three methods for backing and restoring the operating system and networking parameters.
- Snapshot and Revert – Snapshots can only be performed on Splat and backs up everything including the OS drivers; can be used to backup both gateway and management server. File sizes for these backups are usually very large and can only be restored to devices having the EXACT OS, Checkpoint version of Splat and patch level. Command used to perform a snapshot is snapshot_ and must be run from expert mode. By default the snapshot file is stored in the /var/CPsnapshot/snapshots directory. To perform a restore, issue the revert command from expert mode.
- Backup and Restore – The Backup utility is only available on Splat and backups up your firewall configuration as well as networking parameters such as routing. The file size is usually smaller than that of a snapshot because it doesn’t contain any drivers. Can be used to restore to a machine having the same OS, Checkpoint version and patch level. Backups are performed using the backup command; the default location is /var/CPbackup/backups. On UTM-1 and Power-1 appliacnes the default location is /var/log/CPbackup/backups. Restoring is done by issuing the restore command from export mode. Backups are generally performed via the WebUI however restores must be done via the CLI.
- Upgrade_export/Export – Upgrade tools backs up all configuration independent of hardware, OS and Checkpoint version. Migrate utility is used for uprades/migration of database information and can’t be used when downgrading to an earlier version of Checkpoint. File size usually depends on the size of your Policy. Usually this can be done on a live system provided that the CPU isn’t overloaded. Can be run on Splat, Linux and Windows. Upgrade tools on R75 can be found at $FWDIR/bin/upgrade_tools.
Saving Interface and Routing Information
- Windows: netstat -rm > routes.txt – saves route information to text file.
- Windows: ipconfig -a > ipconfig.txt – saves interface information to tex file.
- Splat: ifconfig > ifconfig.txt – saves inferface information to text file.
- Splat: copy /etc/sysconfig/network.C <location>– copies files containing route information to a location defined.
Performing Upgrades
Always upgrade the Security Management Server first before the Gateways.
Migration steps for SMS
- Prepare source machine for export by performing a migrate export which creates a backup of all configurations. Once this is completed, export the file using SCP on Splat or by copying it from its directory on Windows.
- Perform clean install on new server
- Import the database on the new server using the migrate import command.
- Test to make sure everything works before putting into production.
CCSA Home Lab
As most of you may already know by now, I recently relocated to the beautiful Island of Bermuda and started a new gig. Part of my job role will be to deploy and support Checkpoint firewalls. This means that I would need to get up to speed on how these firewalls work pretty quickly. Given this, I figured it would be a good idea to blog about my experiences with these devices as a way to both understand and store my thoughts for future references.
Building a home lab for my studies turned out to be a whole lot easier than I had first anticipated. Everything I needed to be able to study for the exams and also practice deploying the devices could be virtualized. Below you can find my home lab blue print.
- Lenovo ThinkPad with 8GB of RAM and lots of disk space.
- VMware Workstation 7
- Two Windows Server 2003 VMs
- One Windows 7 (host install on my laptop)
- Two Security Gateways
- One Security Management Server
- Checkpoint SecurePlatform R75.20
One of the 2K3 VMs was configured with the RRAS role to act as a router while the other was used just as a general client sitting behind the firewall. Any client OS such as Windows XP/Vista/7 can work but I was too lazy to install another OS, so I copied the VM for the server 2K3 🙂 . I also used my windows 7 host OS as a client sitting behind one of the gateways; this way I was able to do ping tests to the remote site when testing my VPN configurations.
As you can see, it’s a very basic setup, but should allow me to test most of the stuff relevant to the exams.
Backing up Putty Configuration
Being in Networking and dealing with Cisco gears on a daily basis requires the use of a terminal application in order to configure and manage your devices. I’ve used both SecureCRT and Putty but I find myself using Putty a whole lot more. It’s a small application that doesn’t even require an install before you can use it. You simply download and run it. It’s also freeware which is an added bonus.
Due to the number of problems I’ve had with Windows and my laptop, I found myself having to reload quite a number of times. Each time resulting in me losing all my device profiles I had configured and saved in Putty. Because of how the program is written there is no configuration file(that I know of) that I can save and then import whenever I do a new install. This totally sucked, as I was able to backup my configs using SecureCRT. Doing some research led me to this article that showed exactly how to export/import your configurations in Putty. To avoid me having to google around again for such an article just in case I need it in the future, I’ve decided to simply make a copy of the steps required here for my convenience. All credit goes to the author of the article mentioned above for writing such a detailed post on the how to accomplish this.
Steps:
- Open Regedit.
- Look for “SimonTatham” by using the find option (ctrl f).
- Export the reg file by clicking Export from the File Menu.
- Choose the path to store the registry key and hit enter.
- To import the settings in a new Desktop simply copy the registry key to that system and double click to apply the registry setting. At this stage you simply download Putty on the new system and run it, you will notice that all your devices are already populated in the list.
This will definitely benefit me in the future and hopefully those of you who aren’t yet aware of how to backup your configs.
BGP Design #FAIL
Over the past couple of weeks I’ve been experiencing a strange problem with one of our client’s network. They payed for a 5Mpbs connection but had the ISP opened up the pipe to 100Mbps temporarily to their DR site to allow for the initial replication of servers to move a lot faster. The problem was that we weren’t getting anything close to 100Mbps whenever we did speedtests. Results averaged in the 40Mbps range and sometimes it would even get as low as 18Mbps.
Before I go any further, let me give you a brief overview of the current design. The client has their own /24 block and ASN. The same ISP that is providing their primary internet at HQ is also providing internet at the DR site along with the lease line that connects them. eBGP relationships have been established to the ISP at each site along with an iBGP peering between the HQ and the DR. They’re also using EIGRP as their IGP.
After the above configurations were completed I performed some initial tests. We were receiving a partial table at the DR site while only getting a default route at HQ. To prevent the upstream ISP sending the full table unexpectedly I configured a prefix list at both sites to only allow a default route in. Further tests were performed to ensure IGP was routing properly and that both sites were learning routes from each other. The issue arose when we were ready to test replication of the servers at HQ to the DR site. The ISP informed us that they had opened up the pipe to 100Mbps and that we could begin replication. However, conducting a number of bandwidth tests on speedtest didn’t concur with their confirmation. Speeds were fluctuating greatly but didn’t get anywhere close to 100Mbps. This was where the troubleshooting process began and what highlighted my BGP design #FAIL.
Now there could be any number of reasons why I wasn’t getting the desired results. So how do you go about troubleshooting such an issue? A carefully planned process and my good old buddy google. That’s how! The next step I did after testing on my laptop was to test on some other desktops and servers in the network. This would allow me to eliminate my POS laptop that freezes a zillion times a day out of the equation. The tests performed on the servers yielded the same results. Ok, so now we’re moving on to the next set of tests to perform. Before performing anymore tests internally I decided it would be more productive to test from the ISP’s fibre switch and walk my way into the network. It really didn’t make any sense performing a bunch of tests on the internal network when the problem might be with the ISP’s switch, the border router or even the PIX(shoot me now) that are all inline before hitting the internal network. The link comes in from the ISP via fibre, into their switch and then connects to the border router via ethernet. The border router then connects to the PIX. To ensure I was getting the desired bandwidth from the ISP I connected my laptop the to the fibre switch, placed the IP address used to peer up and then perform tests. Results were good. I was getting 98Mbps on average. Ok, so this proves that we are indeed getting the full bandwidth. The next step was to connect back the fibre switch to the border router then connect the router to my laptop. The results of these tests weren’t promising. So now I’m baffled. Could it be the border router? It can’t possible be! It’s a brand new 2901 ISR generation2 and as you know, the new ISRs are built to handle a lot more bandwidth. Time to hit up my friend google. I found another user with the exact same model router with the exact same design using a fibre switch from their upstream ISP, who was having the exact same problem. A lot of users were saying it could be a duplex/speed issue with the ports however this wasn’t the case for me as both the speed and duplex negotiated correctly. I saw @jastorino on skype around the same time I was researching the issue so decided to pitch my problem to him see what input he had. One idea that came up was that it could be possible that the ISP was doing rate limiting via sourced traffic. This made sense as when I connected directly to the ISPs switch using their IP I got full bandwidth, but when I connected to the router using IPs from the client’s block we didn’t. They denied that they were rate limiting as I was suggesting. At this point I knew I must be on to something. Why would I get full bandwidth when traffic was sourced from the ISPs IP but didn’t when it was sourced from the client’s IP. Something’s not right. Moving on, I checked to see how the client’s block was being seen as reachable from a couple of BGP looking glass. Performing a traceroute to an IP at the HQ revealed something quite interesting. The path traffic was taking to reach HQ was through the DR site. This meant that traffic was not taking the same path to return into the HQ network as the path used by exit traffic. This lead to a loud outburst of ooooooooooooooooooooh while at my desk :). Everyone around me wanted to know what happened. So now I’ve found the problem! The internet facing link at the DR site wasn’t opened to 100Mbps while the lease line was. Return traffic was actually being limited by the DR’s internet link. How do I fix it? My first thought was to split the /24 block into two /25 then reconfigure BGP to advertise those blocks to the upstream. This would allow return traffic to take the same path a the exit traffic depending on which block it was coming from. Unfortunately because ISPs wouldn’t advertise any prefix smaller than a /24 this was no longer an option. Using AS prepending was the next fix for this scenario. Prepending the client’s AS 3 times at the DR site made the AS path appear much longer than that of the HQ and because of BGP’s path selection process, return traffic would choose the HQ site.
I know this probably isn’t the best solution but it worked just fine for me. I’m by no means an expert at BGP. However, working on this project exposed me to a lot of good factors about the protocol that I will be sure to take into consideration during future designs.
Today’s Random Voice Experiences.
Today’s task was to deploy a couple of 7962 Phones along with some 7915 Expansion Modules. This shouldn’t be too bad. All I need to do is head over to the client with the gear and configure their CME to accept the new phones and modules. How hard could this be? This should take me probably 2 hours max! Heh! Don’t know who I was kidding. By now I should be well aware that nothing goes as planned in networking, more so in Voice :-).
So I’m over at the client and begin by unpacking the phones, connect them up to the switch and begin my CME configurations. Ephones created, phone registers just fine and hey! I was even able to successfully place a test call. Things are progressing as planned. Next up is to test the expansion modules. Connected up the 7915 modules but for some reason they wouldn’t power up. Did a quick search on google and turns out that these modules need power supplies if the phones are power via POE which was the case here. If the phones are powered via power supply, then you don’t need a separate power supply for the first module. However, for the second module you most definitely require a power supply. Good points to know. So after heading back to the office to acquire a power supply, I was able to get the modules powered up. Now they powered up just fine but didn’t display the lines they were configured for. They just sat there stuck with the amber lights on. Time to hit up my buddy google again. He pointed me to some really cool forums which informed me that the firmware on my phone needs to be at 8.4( they’re currently 8.3 at this stage). Five minutes later and I have ver 9.2 downloaded and copied to the UC560. Rebooted the phones so that they can begin the upgrade process only to be hit with more good fortune. For whatever reason these phones weren’t upgrading. The process kept failing. Eventually I think I tried so many different stuff that the phone would not complete the boot process anymore and load it’s configuration. It would just stay stuck at “Upgrading” and then reboot, going through this cycle repeatedly.
At this point I figured da hell with it! Reset this baby to factory default and start over. If you head over to Cisco’s site for instructions on how to restore this model phone to factory default, they state this. After ensuring that I had everything in place as advised, I proceeded with the reset sequence. This proved to be unsuccessful. After entering 123456789*0# the phone simply went back to the state of “Upgrading”. My frustration level at this point was of course reaching max. Ok, so time to turn on some debugs and go from there. Enabling debugs for tftp enabled me to see what files the phone was looking for. First file I noticed it was not finding was “term62.default.loads”. Rechecking my tftp-server configurations revealed that I had the alias configured incorrectly, leaving out the .loads which prevented the phone from finding the file. I corrected this and proceeded with the factory reset procedure once again only to be greeted with the same error. This time the file that couldn’t be located was “jar42sccp.8-3-3ES2.sbn”. This one really puzzled me as the tftp configurations for this file was correct! This was where the engineer in me came to life! Comparing the firmware files I noticed that the very first file the phone looks for “term62.default.loads” was a lot smaller than the other files. It was 1KB to be exact, when compare to others that were 2439KB. This lead me to believe that this file probably just contained instructions. Opening the file with notepad revealed some gibberish followed by an orderly list of files. The files in this list were the same firmware files but in a particular order. Comparing the order the files were listed in to the order I had my tftp-server statements showed that my statements were in a different order from that of the list. This got me to thinking that maybe I should reorder my statements to the same order that was in the file. This indeed proved to be the problem because as soon as I reconfigured my tftp-server statements the phone successfully restored to factory default. Ok, so I’m some what relieved at this stage. I got the phones back to a working state however, the 7915 module still doesn’t work as we’re back to the 8.3 firmware. I proceeded to use the same logic used to perform the factory restore and retried upgrading the firmware with ver 9.2. This too was successful and the module booted up and dispalyed it’s configuration correctly.
I highly doubt this is how this procedure is supposed to work, though. What happens if your tftp server isn’t the CME device and it’s actually a server? How does it know the order? Maybe this was just a bug in my case as I haven’t seen any other reports of this while researching the issue. In anycase, it was a learning experience, one that will surely help me in the future should I encounter this problem again.
Cisco Unity Express and Loopback0
I’m currently working on a VOIP project consisting of a pair of UC560s and some SPA508G Phones. Configuration for the project is pretty straight forward as no fancy or complex translation rules need to be created. The client is basically replacing their current antique Nortel system with a modern Cisco solution.
The steps required for me to get the system up to a basic state to perform tests were as follows:
- Configure a DHCP Pool for all IP Phones.
- Copy tftp files for the SPA508G phones to flash.
- Configured UC560 to serve up the files so that the phones are able to download their configuration.
- Basic ephone-dn and ephone configurations to test phones.
- Create and assign IP to loopback interface.
- Configure Service-Engine interface to use loopback interface
- Configure IP address and default-gateway of CUE
- Test connectivity to CUE by pinging interface and also establishing connection.
- Configure user accounts in CUE and assign Voicemail mailboxes to users.
- Perform Tests.
As you can see from the list, this truly is a simple deploy.
All configurations were proceeding just fine until I arrived at step 8. At this stage I should be able to both establish a connection to CUE and also receive replies from pings. However this wasn’t so. For some reason all my ping tests were failing. I checked, rechecked, checked again, then checked again to make sure my configs were correct.
Here’s an example of what the configuration would look like.
!Loopback interface created to use with our Service Engine interface. (Cisco's recommended way of configuring it) interface Loopback0 ip address 192.168.1.1 255.255.255.0 !Service Engine interface used to communicate with the Cisco Unity Express. interface Integrated-Service-Engine0/0 description Loopback interface used to manage integrated application module ip unnumbered Loopback0 service-module ip address 192.168.1.2 255.255.255.0 service-module ip default-gateway 192.168.1.1
Did I miss anything? From the configuration we see that the IP Address of the CUE is 192.168.1.2 and the IP address used to communicate with the CUE is 192.168.1.1 which is the IP of the Loopback interface.
For reasons unknowing to me, this configuration was not working. I was able to successfully establish a session to the CUE, logged in using the same credentials used to login to the UC560 and I was able to proceed with further configurations tasks. I was able to create user accounts, assign them mailboxes, assign Voicemail number so that the application is activated whenever that number is dialed etc. Unfortunately ping tests were still failing and as such when I made a test call to Voicemail, it did not work. There is one step I forgot to include in the list above, and that was to create a dial-peer so that whenever users dialed the Voicemail number it would use that particular dial-peer to transfer the call to the correct destination thereby activating the Voicemail system. This was also completed and the configuration for this can be seen below.
dial-peer voice 2 voip destination-pattern 600 session protocol sipv2 session target ipv4:192.168.1.2 dtmf-relay sip-notify codec g711ulaw no vad
I spent hours researching Cisco’s documentation and reading through different forums. Eventually I saw a user on IPexpert’s OSL was having the same issue. He was able to access and ping CUE whenever he used a physical interface or a SVI as opposed to using a Loopback interface. I decided to test this out for myself by using an SVI, Vlan1 and changed the configuration on the Service Engine to use Vlan1 instead of Loopback0. Of course this worked flawlessly! I was able to ping the CUE IP which enabled me to proceed with my further configuration and testing.
I found the whole thing really interesting, as no where on Cisco’s site mentioned there being instances where the Loopback interface wouldn’t work. Have any of you VOICE folks out there experienced this problem before? Did I miss something with my configs? And please don’t tell me that I needed to reboot/reload/reset CUE as I did this so many times till at one point I had to do a complete factory reset to get basic communication again. 🙂
First encounter with IP Fragmentation and MTU problems
About a week ago, I was called to a client to investigate issues they were having as it pertains to browsing the internet. To my surprise when I arrived on site and tested the sites they were having issues with, I was able to browse these sites just fine. At first I was told that there were only 2 users having the problem so I decided to check these two laptops to ascertain whether there was some virus on the system that was causing the problem. This of course proved to not be the case, as both laptops were fully protected and virus definitions were up to date. I did some further investigations on the systems, only to discover that all users on the network were experiencing the problem. This puzzled me even more. To prove whether is was a problem with the internet connection, one of the users informed me that he had connected to a near by wifi connection and was able to browse these same sites just fine. This meant that the problem had to lie within the network.
Upon doing some initial research off site on what possible causes for the problem could be, I was advised that it could be a problem with MTU. Given that I never experienced this issue before, I had to dig deeper to get further details. The customer was using Cisco equipment for their switching infrastructure and Juniper for their firewall. I proceeded to take a ASA 5505 on my next visit to the client and swapped out the juniper to test. The tests were successful. All users were able to browse the websites they were having issues with. At this stage I figured we must have had a defective Junos box on our hands so I swapped it out for a replacement that was already on site. Alright, so now we’ve got a brand new spare Juniper SRX in to replace the old one. All should be fine now, right? Wrong! Users began to experience the same issue again. This of course boggled my mind even further. I mean, the internet worked fine with the ASA. I swapped out the old Junos for a replacement, and we’re back with the same problem? What could be the cause?
Back at the office, I was digging deeper, trying to learn as much as I can about the symptoms that can arise whenever you experience MTU issues. Cisco had a great article about this, which totally went in depth about the causes and possible solutions to the problem. If you’d like to read it for yourself, you can have a look here. I am by no means familiar with Juniper configurations and the Junos box was managed by another team in Holland. Given how technology works, and how all vendors have basically their own way of achieving the same results, I knew that Juniper must have had an option similar to Cisco’s “ip tcp adjust-mss” command and after some research, I came across this Knowlege Base article about how to achieve the same result in Junos. Working along with the team in Holland, I instructed them of the changes to make and also provided the link to the KB. Users were able to browse all sites just fine once again after the changes were made to the Junos box.
For those of you who are wondering how I was able to browse just fine on the network before the Junos box was configured and other users weren’t; my laptop had the Cisco VPN Client software installed. This application usually reduces your MTU to 1300. By default Windows uses a MTU of 1500, so if somewhere along the path to the destination, a device was configured for a smaller mtu you could experience the problems as mentioned above.
BGP Route Reflectors and Confederations
The Border gateway protocol (BGP) is used to exchange network layer reachability information (NLRI) between Autonomous Systems. Like most routing protocols, BGP also has methods of preventing routing loops within networks. iBGP in particular uses the Split Horizon rule to prevent routing loops. The iBGP Split Horizon rule basically states that an iBGP router will not forward any prefixes learned via iBGP to other iBGP speakers because it assumes a full mesh topology. This means that if you have four routers, R1, R2, R3, R4 connected in a daisy chain. R1 being in AS 100 and R2, R3, R4 being in AS 200, any routes learned by R2 via its eBGP peering to R1 wouldn’t be advertised to R4.
To combat this problem, BGP uses two technologies with the goal of allowing your iBGP routers to still receive all routing updates and not require a full mesh topology.
- BGP Route-Reflectors
- Route-reflectors allow iBGP speakers to have a partial mesh topology while still propagating all iBGP learned routes to all iBGP speakers
- Route-reflectors consist of route-reflector servers and route-reflector clients
- eBGP routes learned by route-reflector servers are advertised to other eBGP neighbors, route-reflector clients and non-clients.
- iBGP routes learned from non-clients are advertised to eBGP neighbors and route-reflector clients
- iBGP routes learned from route-reflector clients are advertised to other clients, non-clients and eBGP neighbors.
- BGP Confederation
- Confederations achieve the same goal as Route-reflectors
- This is done by dividing the main AS into several smaller sub-autonomous systems.
- Typically the private range used for these sub ASs are in the range 6451-65535
- Neighbors in each sub-as must still be fully meshed
- Confederation iBGP/eBGP peers act the same way as BGP iBGP/eBGP peers.
Let’s first take a look at how we would configure route-reflectors followed by confederations. We’ll be using the topology consisting of 4 routers, R1-R4 as shown below.
Base Configuration for R1
R1#sh run | s router bgp router bgp 100 no synchronization bgp log-neighbor-changes network 1.1.1.1 mask 255.255.255.255 network 2.2.2.2 mask 255.255.255.255 network 3.3.3.3 mask 255.255.255.255 network 4.4.4.4 mask 255.255.255.255 network 192.168.1.0 neighbor 192.168.1.2 remote-as 200 no auto-summary
Base Configuration for R2
R2#sh run | s router bgp router bgp 200 no synchronization bgp log-neighbor-changes network 192.168.1.0 network 192.168.2.0 neighbor 192.168.1.1 remote-as 100 neighbor 192.168.2.3 remote-as 200 no auto-summary
Base Configuration for R3
R3#sh run | s router bgp router bgp 200 no synchronization bgp log-neighbor-changes network 192.168.2.0 network 192.168.3.0 neighbor 192.168.2.2 remote-as 200 neighbor 192.168.3.4 remote-as 200 no auto-summary
Base Configuration for R4
R4#sh run | s router bgp router bgp 200 no synchronization bgp log-neighbor-changes network 192.168.3.0 neighbor 192.168.3.3 remote-as 200 no auto-summary
Now let’s take a look at the output of the “show ip bpg” command.
Notice that R2 has learned about the loopbacks that are configured on R1 via it’s eBGP relationship with R1.
R2#sh ip bgp Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 192.168.1.1 0 0 100 i *> 2.2.2.2/32 192.168.1.1 0 0 100 i *> 3.3.3.3/32 192.168.1.1 0 0 100 i *> 4.4.4.4/32 192.168.1.1 0 0 100 i * 192.168.1.0 192.168.1.1 0 0 100 i *> 0.0.0.0 0 32768 i * i192.168.2.0 192.168.2.3 0 100 0 i *> 0.0.0.0 0 32768 i *>i192.168.3.0 192.168.2.3 0 100 0 i
Notice R3 also learns of R1’s loopbacks but this time via iBGP as indicated by the “i” in front of the networks.
R3#sh ip bgp Network Next Hop Metric LocPrf Weight Path *>i1.1.1.1/32 192.168.1.1 0 100 0 100 i *>i2.2.2.2/32 192.168.1.1 0 100 0 100 i *>i3.3.3.3/32 192.168.1.1 0 100 0 100 i *>i4.4.4.4/32 192.168.1.1 0 100 0 100 i *>i192.168.1.0 192.168.2.2 0 100 0 i * i192.168.2.0 192.168.2.2 0 100 0 i *> 0.0.0.0 0 32768 i * i192.168.3.0 192.168.3.4 0 100 0 i *> 0.0.0.0 0 32768 i
Here on R4 we see the iBGP split horizon rule in effect.
R4#sh ip bgp Network Next Hop Metric LocPrf Weight Path *>i192.168.2.0 192.168.3.3 0 100 0 i * i192.168.3.0 192.168.3.3 0 100 0 i *> 0.0.0.0 0 32768 i
R4 doesn’t learn of R1’s loopback interfaces because R3 isn’t passing the routes on. To correct this problem we’re going to use the first solution available to us, by making R3 a route-reflector server and R4 a route-reflector client. This will then allow R3 to advertise R1’s loopback interfaces to R4. The configuration to make all this happen only needs to be configured on the route-reflector server which is R3 in this case.
Route-reflector configuration for R3
R3(config)#router bgp 200 R3(config-router)#neighbor 192.168.3.4 route-reflector-client
Now let’s take another look at the output of the “show ip bgp” command on R4 to see if it did indeed learn those routes.
R4#sh ip bgp Network Next Hop Metric LocPrf Weight Path *>i1.1.1.1/32 192.168.1.1 0 100 0 100 i *>i2.2.2.2/32 192.168.1.1 0 100 0 100 i *>i3.3.3.3/32 192.168.1.1 0 100 0 100 i *>i4.4.4.4/32 192.168.1.1 0 100 0 100 i *>i192.168.1.0 192.168.2.2 0 100 0 i *>i192.168.2.0 192.168.3.3 0 100 0 i * i192.168.3.0 192.168.3.3 0 100 0 i *> 0.0.0.0 0 32768 i R4# R4#ping 4.4.4.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
Success!!! We see that R4 is indeed now learning the routes via it’s iBGP neighbor R3 and we also have reachability.
Moving onto BGP Confederations. For this example we’re going to use the same topology however we’re going to sub-divide AS200 into As6500 and AS6501
One thing to note about Confederation configurations is that we first create the sub AS and then identify what our actual AS is within BGP sub configuration mode. I personally don’ t know why Cisco decided to implement Confederations in this way but this wouldn’t be the first time we’ve all scratched our heads at how Cisco chooses to implement stuff. Configurations for R1 will remain exactly the same, however for all other routers in AS200 (Confed AS 6500 and AD6501), we’re going to have to first remove the “router bgp 200” configs then proceed with the configurations. R2 and R3 are going to be placed into sub AS 6500 while R4 will be placed in sub AS6501.
The reason for us placing R4 into a separate sub AS to R2 and R3 is because Confederation iBGP/eBGP peers act exactly the same way as iBGP/eBGP peers. This means that a full mesh would still be required for all routers within the same sub AS. Had we placed R4 into the same sub AS as R2 and R3 the split horizon rule would have prevented R3 from advertising the networks on R1, to R4.
Confederations config on R2
R2#sh run | s router bgp router bgp 6500 no synchronization bgp log-neighbor-changes bgp confederation identifier 200 bgp confederation peers 6501 network 192.168.1.0 network 192.168.2.0 neighbor 192.168.1.1 remote-as 100 neighbor 192.168.2.3 remote-as 6500 no auto-summary
Confederations config on R3
R3#sh run | s router bgp router bgp 6500 no synchronization bgp log-neighbor-changes bgp confederation identifier 200 bgp confederation peers 6501 network 192.168.2.0 network 192.168.3.0 neighbor 192.168.2.2 remote-as 6500 neighbor 192.168.3.4 remote-as 6501 no auto-summary
Confederations config on R4
R4#sh run | s router bgp router bgp 6501 no synchronization bgp log-neighbor-changes bgp confederation identifier 200 bgp confederation peers 6500 network 192.168.3.0 neighbor 192.168.3.3 remote-as 6500 no auto-summary
Output of “show ip bgp” on R4
R4#sh ip bgp Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 192.168.1.1 0 100 0 (6500) 100 i *> 2.2.2.2/32 192.168.1.1 0 100 0 (6500) 100 i *> 3.3.3.3/32 192.168.1.1 0 100 0 (6500) 100 i *> 4.4.4.4/32 192.168.1.1 0 100 0 (6500) 100 i *> 192.168.1.0 192.168.2.2 0 100 0 (6500) i *> 192.168.2.0 192.168.3.3 0 100 0 (6500) i * 192.168.3.0 192.168.3.3 0 100 0 (6500) i *> 0.0.0.0 0 32768 i
Success!!! R4 learns of R1’s networks via it’s Confederation eBGP relationship with R3. Notice that the networks do not list the “i” in front of them to indicate it as being learnt via iBGP. This shows clearly how similar Confederation eBGP peers and normal eBGP peers are in terms of their neighbor relationships.
As we’ve seen throughout this post, both Route-Reflectors and Confederations can be used to solve the iBGP Split Horizon problem without the need for a full mesh topology within your BGP networks. I personally don’t have any production experience dealing with these technologies but if I had to choose one, I’d go with route-reflector just because the configuration is a lot simpler :-). Also one other advantage that came up during my group study session with @aconaway was that you would need to plan ahead if you ever wanted to implement Confederations. Reason for this is because the way in which BGP Confederations are configured in IOS. Let’s say we had some eBGP peers early in our network when it was a lot smaller but now your network has grown to a size that requires Confederations. You would need to remove the “router bgp AS” command thereby removing all BGP configurations on that router, then proceed with your Confederation configs where as with route-reflectors you simply need to place the “neighbor x.x.x.x route-reflector-client” command to achieve the same result.
Disclaimer
This post was mainly written to aid me with my studies. The views expressed are based on my understanding and research of the technologies. Because this is a learning process mistakes may be committed to which I would greatly appreciate it if you would point those out via the comments section.
MCITP EA Completed! What’s Next?
So, I finally managed to complete the final two exams remaining to achieve my MCITP Enterprise Administrator.
These were:
- TS: Windows Server 2008 Applications Infrastructure, Configuring (Exam 70-643)
- Pro: Windows Server 2008, Enterprise Administrator (Exam 70-647)
No doubt, these two were definitely tougher than the previous exams taken to achieve MCTIP SA. I think this was mainly because of the new technologies that were covered.
The 70-643 exam focused more on being able to prepare your network environment for the different applications/technologies being deployed in today’s enterprise. Virtualization and Remote Desktop Services played a big part in this. Microsoft really has implemented a lot of improvements into the Remote Desktop Service role, formerly Terminal Services. One such improvement that I am very impressed with is that of the Remote Desktop Gateway. Before, the only way of allowing remote desktop access to internal terminal servers/client desktops, would have been to open port 3389 on your company’s firewall and forward that port to the particular system or you would need to install a third party software like Logmein. With Remote Desktop Gateway, we now have the option of using port 443, which is already open on many corporate firewalls, to allow remote desktop access to internal client desktops. Topics covered also included:
- Deploying Servers
- Configuring Remote Desktop Services
- Configuring a Web Services Infrastructure
- Configuring Network Application Services
Windows Server 2008 Enterprise Administrator is the professional exam required to complete the MCITP EA. This exam is focused more on the design aspects rather than exact configuration steps required for a particular scenario. This was definitely the most difficult of all the exams I took for the MCITP SA/EA. Some of the topics covered were:
- Planning network and application services
- Designing core identity and access management components
- Designing support identity and access management components
- Designing for business continuity and data availability
So now that I’ve completed this, you may be wondering what’s next. I’m going to be going after the MCTIP Enterprise Messaging Administrator 2010. I’ll go into further details in a later post describing why I chose this as my next cert and what training materials I’ll be using. For now, I just wanted to give you a short update on my studies.
Jason Harry's Blog 