QinQ on Nexus 3524s

Will cisco confirm that dot1q-tunneling is not a supported feature under a 35XX nexus switch. The 30xxs support and IIRC the 5K also.

This is confirmed even under the latest code that 's available under the 6.0 family.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

HOWTO license a Nexus SWITCH

This post will show you the few & simple steps with licensing a feature license on Nexus switch. The process is non-service impacting and takes approx 5 mins or  even less.


1st you need to find your license information as provided via the reseller. Take note of the circled info.

NOTE: The PAK is provided and will be applied to the device via serial #

Now, you need to  browse over to the cisco activiation website and fill in a few details such as the device PAK id and serial number of the device. You can use the "show inventory" cmd for gaining your system serial#.

Upon completion,   you will receive the license file in a zip format via the email associated to your CCO profile, just unzip the file copy the license.lic file to the device via SCP or some other means.

Now the fun part begins;

1:  make a backup of the running cfg ( copy run start ) and ( copy run bootflash:mybackup.cfg )

2:  backup your existing license via the  ( copy license  ) cmd;

note: the file-name specified has to end with an  .tar  extension or the system will fail.  If  you  try to backup against a name already defined, it too will fail also


3:  now you can install the new license that you copy to the device from bootflash or usb1; or wherever  you have it installed;

If you ever should need to remove a license, repeat the backup steps mentions above, but now use the following command;

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

VLAN cisco reservation internal usage ( thoughts )

With Vlan IDs  we have some that we  should be avoid & this issue bound to come up in big networks with hundreds if not thousands of vlans.

The following show command  under IOS/NX-OS will display these internal usage vlans;

e.g

show vlan internal  usage

If you try to configure a vlan that's used internally, you will have an error similar to the  below.

Now luck has it that cisco has created a means for reserving  vlans. It's sometime best to apply this practices in big SP/ENTERPRISE networks to avoid design issues  that could later conflicts with a reserved vlan.

Our socpuppets general thought has always been to craft vlans under the 4K range,  and build a vlan allocation sheet that you SHOULD always review b4 vlan allocations.

The "vlan internal  allocation policy ascending" or "vlan internal  allocation policy descending" commands can help in determining the internal vlan allocation methods.

NOTE: I believe this is a IOS command and not widely deploy under most  NX-OS switches.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

NX-OS howto md5 check 3500s

On a nexus 3524 you can use the following means for file md5sum checking & file-image integrity. The size of the file will determine how long it takes to complete the md5sum verification.


show bootflash:<filename>  md5sum

E.g

NOTE : The NX-OS will also perform a image verification when setting the boot var

E.g

or you can execute the following;

E.g

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

SIP registering issues cisco ASA

In this blog we will look at a sip UA client ( X-lite ) and using the call centric services. One of the biggest problems with  SIP clients soft or hardware based ,  involves with the SIP  registrations.

A few reasons that can cause a SIP REGISTRATION or failures

•  bad sip domain specified at the client
•  username incorrect ( SIP register name = Sip.To ) 
•  bad  sip account password
•  the firewall filtering your protocol and ports ( TCP|UDP port5060/5061 )
•  ALG not enabled  nor fixing up the SIP header
• lack of re-REGISTERs or lack of SIP-KeepAlives
• severe packet lost preventing registering ( not common but could happen )
• you have trip the max registers per client or some Admission controls thresholds ( usually this is set at the SIP provider server/proxy )

Here's a SIP-register from my X-lite client on my MACOSX client

Now the firewall plays an important process. It must fixup the SIP REGISTER and mask the  SESSION details to match your public SNAT address if NAT is enabled between the UAC and UAS.

Obviously you must have firewall policies that allows the traffic outbound from your client to the sip server to begin with.

NOTE:  With the call centric the protocol for registering is done via SIP using defector udp/5080. Some clients will revert to TCP and even to ports 5060 |5061 as an alternative but you need to double each client and what the SIP provider is expecting. In my  X-lite and Callentric  they use 5080 which is typically the default for Sip clients that uses proxy-registration  versus a sip trunk Carrier which hardly uses SIP-REGISTERs.


For "Bad" authentication , is actually easy to determine if this has happen by monitoring  the SIP status-codes between client and server.

1   9.698676 10.200.41.89 -> 204.11.192.22 SIP 610 Request: REGISTER sip:callcentric.com  (1 binding) | 

  2   9.941065 204.11.192.22 -> 10.200.41.89 SIP 553 Status: 407 Proxy Authentication Required | 

  3   9.942312 10.200.41.89 -> 204.11.192.22 SIP 811 Request: REGISTER sip:callcentric.com  (1 binding) | 

  4  10.186344 204.11.192.22 -> 10.200.41.89 SIP 386 Status: 403 Incorrect Authentication | 

  5  15.373261 10.200.41.89 -> 204.11.192.22 SIP 610 Request: REGISTER sip:callcentric.com  (1 binding) | 

  6  15.633247 204.11.192.22 -> 10.200.41.89 SIP 553 Status: 407 Proxy Authentication Required | 

  7  15.635155 10.200.41.89 -> 204.11.192.22 SIP 811 Request: REGISTER sip:callcentric.com  (1 binding) | 

  8  15.883003 204.11.192.22 -> 10.200.41.89 SIP 386 Status: 403 Incorrect Authentication | 

  9  27.379048 10.200.41.89 -> 204.11.192.22 SIP 610 Request: REGISTER sip:callcentric.com  (1 binding) | 

 10  27.626802 204.11.192.22 -> 10.200.41.89 SIP 553 Status: 407 Proxy Authentication Required | 

 11  27.628884 10.200.41.89 -> 204.11.192.22 SIP 811 Request: REGISTER sip:callcentric.com  (1 binding) | 

 12  27.894571 204.11.192.22 -> 10.200.41.89 SIP 386 Status: 403 Incorrect Authentication | 

NOTE: It doesn't tell you what was wrong other than your authentication was incorrect. It could have been username,  password or both, remember the server & client are using a cryptographic nonce to ensure the password is hash to a value that can't be replayed. So if the domain is correct, just  rekey the username and password


Now with the cisco ASA, all we need to do is to ensure our  policy-map has sip inspection enabled and to ensure it's applied globally or on the interface.

Here's a typical ASA policy-map cfg;

policy-map global_policy

 class inspection_default

  inspect ftp 

  inspect h323 h225 

  inspect h323 ras 

  inspect ip-options 

  inspect netbios 

  inspect rsh 

  inspect rtsp 

  inspect skinny  

  inspect sqlnet 

  inspect sunrpc 

  inspect tftp 

  inspect xdmcp 

  inspect pptp 

  inspect ipsec-pass-thru 

  inspect icmp 

  inspect icmp error 

  inspect http 

  inspect snmp 

  inspect dns preset_dns_map 

  inspect sip  

 class internal_network

  inspect esmtp 

 class class-default

  inspect pptp 

  user-statistics accounting

You can use the following show commands to confirm inspect for SIP;

show service-policy inspect sip table

And for monitoring any flows

show conn protocol udp port 5060-5061 long

show conn protocol tcp port 5060-5061 long

or

show conn protocol udp port 5080 long

And you can monitor the expiration and refresh to get an ideal of how long your sessions are up and when they refresh, this should match the SIP keepalives intervals  for the UAC

UDP EXTERNAL02: 204.11.192.22/5080 (204.11.192.22/5080) TRUST01: 10.200.41.89/55589 (1.22.11.100/55589), flags - , idle 1s, uptime 8m18s, timeout 1m0s, bytes 17115

A few other items to think about, do you need 1> SIP re-REGISTER and  2>KEEPALIVES. The answer for this really depends.

But  SIP keepalives will ensure the firewall NAT/SESSION table stays active and does not expire from the  session list. It never hurts to enable a reason SIP session timer.  You can also get by with increase sessions timeout in the  cisco ASA for SIP for the session table

The show run timeout cmd will provide you an ideal for SIP sessions values

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

The choice is all yours on what you need to do, but be aware of the few listed issues that effects SIP registering  and how your Cisco ASA fits into the  picture.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

tips "Fortigate logging for IPS attack events"

One of the biggest gotcha when using  the forties IPS sensor is the lack of logs  in the WebGUI. One easy mistake is forgetting to  enable logging for memory vrs foricloud

Next, you need to enable logging per IPS sensor event.

After your have done the above, you can now witness any Alerts within the log &report > security  from the main page.


Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

Fortimail and cisco cables

In this post I will demostrate the usage of cisco cables SFP-H10GB-CU3M enlew of  SFPs for connecting a FML to a cisco 6509-E.

Most if not ALL Fortinet gear, is pretty much cisco compatible for ALL SFPs that I've used in the past.  You can pretty much use any standard  badged/labeled  cisco SFPs in fortunate gear and it will work.

Here's the  FML 3KD  configuration for the SFP slot interface in the back.

No on the switch I was surprised that cisco showed there own cables not compatible .

NOTE: I'm using the service unsupported transceiver commands on this switch btw.

service unsupported-transceiver

The  cisco gear works find and provides layer2 connectivity to the 3000D FML appliance

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \