Monday 22 February 2010

CME <=> Avaya CM5

I'm currently studying for my CCNA Voice certification. As part of this I have configured a router with CME (Call Manager Express) which is the mini PBX that you can run on a suitable Cisco router.

I have manage to get most of this running as expected as per the methods shown in the very useful CBT Nuggets videos which I have access to through work.

Yet there was one problem. Whilst I could call from Avaya to Cisco and have a proper voice path, calls from Cisco to Avaya failed. I would hear silence after dialling then eventually a busy tone.

I have been scratching my head for a week now trying to work out what was wrong but debug utilities on the Avaya side are nothing like the Cisco ones.

I took to considering the differences between the ideal network topology as shown in the videos where the CME router is configured as a router on a stick, and my own topology, where I have a router with two interfaces. My router had it's own network for the IP phones whilst the Cisco IP Communicator (CIPC) client that I was using was not on this separate network.

I started thinking about source and destination IP addresses. Now whilst the CIPC client had no issues registering from another network presumably due to the ip source-address command under telephony-service. Yet this did not dictate what source IP address the router would use when talking to dial-peers.

Thus whilst I had configured my Avaya to talk to the CME router via it's dedicated NIC, this only worked for call signalling coming from the Avaya. Call signaling coming from CME to the Avaya had a different source IP than the trunk far end I had configured on the Avaya and thus the Avaya was rejecting the call attempt.

I simply updated the Avaya configuration to use the closest IP address (topology wise) and whalla it works. I can now dial from Cisco => Avaya and all details come across!

Lesson to be learned, don't assume things.

Tuesday 16 February 2010

BGP oh the joys

For reasons unknown my internal routing protocol 'lost' it's route to our provider independant address space this morning. The symptoms were a complete loss of access to the Internet. Logging a fault with the relavent ISP returned a 'no problem here' response.

We have redundant Internet feeds so I was confounded that both of them should fail at the same time. Further investigation determined that access to the Internet worked fine using an address from the /30 each ISP provided for connectivity. So it was just our address space.

Whilst waiting for the ISPs to get back to me (I had made it clear it was a routing issue not a service issue) I double checked and lo and behold my gateway routers no longer had a route for our address block. I'm sure I had one before but not having one now meant BGP had nothing to advertise.

BGP is different from other routing protocols in that it will only advertise to other parties (people with a different ASNUM) that which is already in your routing table.

I'm sure I had a route before but thinking about it, I believe the route came from BGP in the first place. It's like a circular argument, it works as longs as you don't stop. So some network change stopped BGP advertising to itself our block of address space and thus it no longer existed in the routing table of my gateway routers, and thus BGP could no longer advertise our block to the upstream providers.

Talk about a chain of events.

So I now have a static route to Null0 for our block to ensure BGP always has something to advertise. I should make it a backup route (high admin distance) so my IGP can insert something if it needs to.

Oh the joys.