30 Mar

ASR1k NAT really does not like secondary addresses

Cisco routers never liked secondary addresses if NAT is configured on same interface. You can always expect unpredictable behaviors, and making translations over secondary addresses never worked. On ASR1k it’s even worse.

Configuration for testing was pretty simple.

interface TenGigabitEthernet0/2/0
 ip address 10.15.15.254 255.255.255.0 secondary
 ip address 130.189.160.161 255.255.255.252
 ip nat outside
!
ip nat pool test-robot 130.189.160.161 130.189.160.161 netmask 255.255.255.252
ip nat inside source list test-r-list pool test-r overload

On ISR this configuration should work, at least I made it run on dynamips and 12.4T software. On ASR1k and IOS XE it’s not working regardless of version of software used. If you enable debugging you’ll find something like that in logs

*Mar 24 06:49:12.482: NAT: setup alias for 130.189.160.161 (redundancy_name , idb TenGigabitEthernet0/2/0, flags 0x2)
*Mar 24 06:49:12.482: NAT: installing alias for address 130.189.160.161, addr_flags 0x2
*Mar 24 06:49:12.482: NAT: alias insert failed for 130.189.160.161

Traffic flows through ASR router, translation entry is created in NAT table and it reaches destination, but almost every traffic that is sent back and should use same translation is dropped by ASR. Almost every because ICMP pings are working fine, UDP and TCP flows are dropped.

There are two solutions of this problem. You can create translation rule using interface instead of pool, then ASR will use primary address as a source of translation and it will work fine.

ip nat inside source list test-r-list interface TenGigabitEthernet0/2/0 overload

Other solution is to split physical interface into two subinterfaces using dot1q tagging and use ip nat outsideonly on subinterface with public addresses.

What’s also disturbing is fact, that NetFlow Event Logger (refer to this post, that should send NetFlow v9 events to collector starts sending weird data. In my tests it stopped sending informations about creation or removal of NAT entry. No data sets were sent to collector, just templates that weren’t the ones described by templateId=259.

23 Mar

Missess counters on Cisco routers

According to Cisco’s documentation misses represents “number of times the software performs a translation table lookup and fails to find an entry, and creates one“. So all routers should have some misses in their counters. Let’s look at some 1841 router statistics:

C1841#sh ip nat statistics 
Total active translations: 3339 (0 static, 3339 dynamic; 3339 extended)
Peak translations: 8114, occurred 18:35:17 ago
Outside interfaces:
  FastEthernet0/0
Inside interfaces: 
  FastEthernet0/1
Hits: 28658670  Misses: 0

No misses, only hits that increases every time “the software performs a translation table lookup and finds an entry“. It works same on every ISR and 7200 routers. But still documentation says otherwise.
Read More

21 Mar

NetFlow Event Logger on ASR1k

ISP’s are not ready yet to deploy IPv6 to end customers and lack of IPv4 address spaces force them to use NAT in their networks. Unfortunately more and more governments require logging what users do and what IP addresses they are connecting to. NAT even logger to syslog is available for quite long time already. But with all AJAX and P2P applications logging, and especially querying logged data is ineffective. On ASR1k routers you can log NAT and firewall events using NetFlow v9.
Read More

15 Mar

Testing SSO on ASR1k

IOS XE on ASR1000 provides two forms of redundancy. First one is well-known hardware redundancy available in ASR1006 where two RP’s and ESP’s can be installed. On other platforms software redundancy and ISSU can be configured. Because IOS XE is in fact just one of a Linux processes running on the platform while system is booting up no one but two instances of iosd are executed in background, but only one is active. Both processes are running on same Route Processor. Standby IOS process can be switched to in the event of an IOS failure, and can also be used to upgrade sub-package software in some scenarios as the standby IOS process in an ISSU upgrade.
Read More

13 Mar

Passing SIP methods in CUBE-SP

CUBE is marketing name of Cisco Unified Border Element, formerly known as Session Border Control. It’s meant to be implemented at the edge of the voice network as an interconnection between two or more VoIP networks providing security between them, CAC, billing etc. There are two models – CUBE known from IRS routers and CUBE-SP available on ASR 1000 and 7600 platform. Both of them works slightly different.

With CUBE-SP not all of the SIP methods are passed through SBC router by default. In example MESSAGE method is not which makes sending text messages between SIP phones impossible. SBC router responds with “405 Method now allowed” if it sees unsupported method in SIP message. But particular methods can be added to whitelist and therefor passed through SBC.

sbc CUBE
 sbe
   sip method-profile Pass-IM-Header
    pass-body
    method MESSAGE
     action pass
   adjacency sip Internal
    method-profile inbound Pass-IM-Header
    method-profile outbound Pass-IM-Header
   adjacency sip Internet
    method-profile inbound Pass-IM-Header
    method-profile outbound Pass-IM-Header

In following example particular method is defined as accepted in method-profile, which is attached in both ways to adjacency. This way we can biuld complex policies allowing devices from one adjacency to pass some methods while blocking from others.

13 Mar

Hi there

This is my small personal space where I want to share some of Cisco’s stuff I’m doing at work or/and free time. Small hints. bigger solutions, news and more will appear here as long as I’ll have time. Working for Cisco’s Gold Partner gives me opportunity to design, deploy and play with most advanced Cisco’s solutions. So enjoy and leave your feedback.