Nexus - SSH Error

Working on a Nexus 5548 last week I came across the following error when trying to SSH to another switch from here.

CORE-01# ssh admin@10.113.150.252
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is70:81:d5:1e:64:51:e5:ba:2d:9a:55:8d:fa:43:59:b8.
Please contact your system administrator.
Add correct host key in /var/home/admin/.ssh/known_hosts to get rid of this message.
Offending key in /var/home/admin/.ssh/known_hosts:8
RSA host key for 10.1.150.252 has changed and you have requested strict checking.
Host key verification failed.

Solution is pretty easy...

CORE-01# clear ssh hostsCORE-01# ssh admin@10.1.150.252
The authenticity of host '10.1.150.252 (10.113.150.252)' can't be established.
RSA key fingerprint is 70:81:d5:1e:64:51:e5:ba:2d:9a:55:8d:fa:43:59:b8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.150.252' (RSA) to the list of known hosts.
admin@10.1.150.252's password:
Type help or '?' for a list of available commands.
EDGE-01> en
Password: *********

This happens when the Nexus switch has a pre-existing SSH key stored for the remote device and the remote device's key changes. The command simply clears the buffer of local SSH keys stored for remote hosts. I've seen this on Linux servers before as well.

Hope it helps. Thanks for reading.

PPPoE Problems on Cisco 2911 Router (TPG EFM / Business Ethernet Broadband)

TPG are a great cheap little ISP, however their support is not crash hot nor their guidance on how to configure network gear to work with them. Basically TPG provide a fairly cheap unlimited data-plan for businesses under the name of EFM (Ethernet First Mile). When you get this service from TPG we received an abrupt email saying simply:

Network Details: 

• Username: user@pig.tpg.com.au
• Password: password 
• CE IP Address: 1.1.1.1/30 
• PE IP Address: 1.1.1.2/30

Then a "test and validate it works within 2 days otherwise we assume it is operational and will start billing" line. So I suppose I need to test this...

The inclusion of the username/password was a little different to what I expected from TPG. I assumed that we'd just get an Ethernet feed and connect into that with an IP address, no questions or authentication asked... however the inclusion of a username/password indicated that a PPPoE connection was required (not that TPG tell you that anywhere from what I can see).

This was not expected... but it was not that big a deal either. I grabbed a 2911 we had sitting around in our lab, connect it up and started googling away for a solution. Guides came up pretty quick for ISR routers with PPPoE... but when trying to apply these configurations to our router I noted that it refused to accept a section frequently referenced in these guides:

vpdn enable
no vpdn logging
vpdn−group pppoe
 request−dialin
  protocol pppoe

Now the section refused is the last line. 2911's don't have the PPPoE option here. You can type protocol but the only option after that is l2tp which didn't help here. Turns out this is another ISR G2 thing. To force the PPPoE to take place you instead have to do the following:

bba-group pppoe global virtual-template 1
vpdn enablevpdn-group 1

Below is the full sample configuration I used:

bba-group pppoe global
 virtual-template 1
!
vpdn enable
vpdn-group 1
!
interface GigabitEthernet0/0
 no ip address
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
!
interface Dialer1
 ip address 1.1.1.1 255.255.255.252
 ip mtu 1492
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication pap callin
 ppp pap sent-username user@pig.tpg.com.au password 0 password
 no cdp enable
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
dialer-list 1 protocol ip permit

Hopefully this saves someone else some hassle. Thanks for reading.

ASA - How to get automatic email notification of firewall failover events?

ASAs have a habit of automatically failing over quietly and efficiently without anybody knowing about it. Sometimes this occurs because an upstream/downstream device rebooted or a switch failed momentarily. What's annoying is that the firewall can failover without you knowing about it at all... sometimes you get stuck focusing on the other issue and never notice the firewalls are in a failed state. I've seen customers who have (thinking they were running on their primary firewall) rebooted their failover infrastructure to find they've caused a short outage to their network.

There are a few ways to find out when an ASA has failed-over without looking at the box or logging into it and doing a "show failover". Firstly you could invest in commercial software/etc... which most smaller companies can't afford to run/maintain ($$$). Open source options might appeal to those inclined. Another way to do this "cheaply" is to use the "logging mail" function which, when a syslog event matching a syslog ID list occurs, sends an email to a recipient with the logging event/s.

So which syslog IDs do you match? Well you have a few options here, you could run a few tests and see what log events occur OR you can find the ASA syslog event list for your ASA code version and figure out the syslog codes that are appropriate.

The table linked specifies HA events as starting with 101, 102, 103, 104, 210, 311, 709. It also says that error codes are between 100000-999999. As you're probably aware there are different "logging" levels that can be applied/viewed/etc... these are typically referenced as a number between 0 - 7 (where 0=Emergencies, 1=Alerts and 7=Debug). It turns out that 1xxxxx numbers are therefore the "Alert" (1) messages and likely the ones we want to see.

So if we matched 101xxx, 102xxx, 103xxx, 104xxx we'll probably see what we want to see. Further snooping/sniffing of alerts tells me that 105xxx is likely needed as well.

logging list SMTP-FAILOVER message 101000-101999
logging list SMTP-FAILOVER message 102000-102999
logging list SMTP-FAILOVER message 103000-103999
logging list SMTP-FAILOVER message 104000-104999
logging list SMTP-FAILOVER message 105000-105999
logging mail SMTP-FAILOVER
logging from-address ASAFirewallAlarm@company.com.au
logging recipient-address SupportTeam@company.com.au level alerts
smtp-server 10.1.1.1

Note: In the above you need a SMTP server configured/available for emailing to work.

I haven't tested the above configuration exactly but have tested a very similar one on a customer's network. It works like a charm!

Hope it helps! Thanks for reading.