Sunday, February 22, 2009

Mpls Lab #1 : Basic Mpls configuration

Hi all, after a successful BGP exam, now it's time to start with MPLS... nothing better than a basic lab to practice the configurations and show commands.

Here the topology, most of my lab routers doesn't support mpls (2600 series) that's why I used GNS3 with 3600s...

STEP 1: configure all point to point links and use EIGRP with various AS to route all links and loopbacks. Ensure that you can ping every interface from every router.

STEP 2: basic mpls configuration, for each router you must:
-enable ip cef with:
ip cef
-set some mpls parameters like:
mpls label protocol ldp   !-- optional... by default is ldp
mpls ldp router-id loopback0 !-- optional, but it's not a bad idea use a loopback as router-id
-enable mpls for eache interface
interface Serial0/0
description R0 <-> R1
ip address 172.17.45.5 255.255.255.252
mpls ip
Well done, now our network is using mpls, time to check it with several show commands:
-we must ensure that mpls is enabled for the correct interfaces:
R0#sh mpls interfaces
Interface IP Tunnel Operational
Serial0/0 Yes (ldp) No Yes
Serial0/1 Yes (ldp) No Yes
-then we must check if we have ldp sessions with neighbours:
R0#sh mpls ldp neighbor
Peer LDP Ident: 172.17.50.13:0; Local LDP Ident 10.26.0.1:0
TCP connection: 172.17.50.13.61893 - 10.26.0.1.646
State: Oper; Msgs sent/rcvd: 89/90; Downstream
Up time: 00:55:11
LDP discovery sources:
Serial0/1, Src IP addr: 172.17.45.2
Addresses bound to peer LDP Ident:
172.17.50.2 172.17.50.13 172.17.45.2 172.17.45.9
Peer LDP Ident: 172.17.50.9:0; Local LDP Ident 10.26.0.1:0
TCP connection: 172.17.50.9.45695 - 10.26.0.1.646
State: Oper; Msgs sent/rcvd: 88/87; Downstream
Up time: 00:55:10
LDP discovery sources:
Serial0/0, Src IP addr: 172.17.45.6
Addresses bound to peer LDP Ident:
172.17.50.1 172.17.50.9 172.17.45.6 172.17.45.13
Note that the "Addresses bound to peer ldp ident" are all the ip addresses assigned to the interfaces of the neighbour. This is used to find the next hop for each prefix in the routing table and identify the ldp neighbour for outgoing label selection.
-now we can see the whole LFIB with:
R0#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Untagged 172.17.45.6/32 0 Se0/0 point2point
17 Untagged 172.17.45.2/32 0 Se0/1 point2point
18 Pop tag 172.17.50.8/30 0 Se0/0 point2point
19 Pop tag 172.17.50.0/30 0 Se0/0 point2point
Pop tag 172.17.50.0/30 0 Se0/1 point2point
20 17 10.40.0.0/24 0 Se0/0 point2point
21 18 10.40.10.0/24 0 Se0/0 point2point
22 19 172.17.45.18/32 0 Se0/0 point2point
23 20 172.17.45.16/30 0 Se0/0 point2point
24 25 172.17.45.14/32 0 Se0/0 point2point
25 Pop tag 172.17.45.12/30 0 Se0/0 point2point
26 Pop tag 172.17.50.12/30 0 Se0/1 point2point
27 17 172.17.45.10/32 0 Se0/1 point2point
28 Pop tag 172.17.45.8/30 0 Se0/1 point2point
29 31 172.17.50.4/30 0 Se0/1 point2point
30 32 172.17.45.17/32 0 Se0/1 point2point
31 32 172.17.45.9/32 0 Se0/0 point2point
32 29 10.31.0.0/24 0 Se0/1 point2point
33 30 10.32.0.0/24 0 Se0/1 point2point
34 33 172.17.45.13/32 0 Se0/1 point2point

Friday, February 13, 2009

WVIC 1MFT-E1 back-to-back connection

After I spoke with Stefano Messia days ago, I would try to connect back-to-back two WVIC 1MFT-E1 to emulate an analog PSTN Pri for testing and lab purposes.
(Altrough I'll start studying CCVP only on july 2009...)

First of all, I need a back-to-back Pri cable, I found this useful post by Conwyn Flavell on the Cisco Learning Network site and cabled a 10 cm ethernet cable with two Rj-45 connectors as follows:

1 RX Ring - -> 4 TX Ring -
2 RX Tip + -> 5 TX Tip +
4 TX Ring - -> 1 RX Ring -
5 TX Tip + -> 2 RX Tip +

When connected, both 1MFT-E1 cards have immediatly turned on the "CD" Carrier Detect light ;-)

The basic configuration to emulate a PSTN Pri will be:

on R1:
R1(config)#
!
isdn switch-type primary-qsig
!
controller E1 1/0/0
pri-group timeslots 1-31
!
interface Serial1/0/0:15
no ip address
encapsulation hdlc
no logging event link-status
isdn switch-type primary-qsig
isdn incoming-voice voice
isdn bchan-number-order ascending
no cdp enable
!

on R2:
R2(config)#
!
controller E1 1/0/0
clock source internal !-- the "pstn network" side must provide clock
pri-group timeslots 1-31
!
interface Serial1/0/0:15
no ip address
encapsulation hdlc
no logging event link-status
isdn switch-type primary-qsig
isdn timer T310 120000
isdn protocol-emulate network !-- this is the PSTN-emulated site (the "network") ;-0
isdn incoming-voice voice
no cdp enable
!

that's all, after my CCIP, planned for mid-june 2009, I'll start some labs on CCVP, so stay tuned! (as usual)

Wednesday, February 11, 2009

Wism Upgrade from 4.1.181.0 to 4.2.176.0

Today we have finished the upgrade of our two Wireless Lan Controllers Wism Modules from 4.1.181.0 version to 4.2.176.0 ... (Thanks to Stefano Messia ;-) )

Some tips, tricks and problems:
  • Read carefully the "Wireless LAN Controller (WLC) Software Upgrade" guide, follow the instruction for software upload via tftp
  • Keep in mind that the upgrade instructions are for a single controller, if you have multiple controllers, you must plan a contemporary upgrade.
    The most important thing is: when I reboot a controller, all my AP will register on the other controllers, if my controller has a new Software release, the AP will automatically download a new mini-IOS the first time (and if it have a older sw version, the ap will dowload and downgrade back ;-( ).

So, I have two controllers, upgraded and rebooted the first, the Ap have registered and downloaded the upgrade.. suddenly during the software download the load balance features between the controllers has moved several Ap to the other (with the old 4.1...) and ...they have downgraded back to the old IOS...!
In fact, with two Wism, one with 4.2.176 and one with 4.1.181, in the middle of the upgrade, there where a sort of Access Point loop, registering on a Wism, downloading the upgrade, moving to the other Wism and downloading the "downgrade" sw...
If there is a downloading access point, you cannot reboot the wism module...
To solve we have shooted down completely the portchannel of the "old" version wism, so we have rebooted it... (extremely discouraged by the instructions ;-( )

Problems POST-upgrade to 4.2.176.0
  1. The DHCP Proxy feature will automatically disabled, so all clients cannot use the service until we have troubleshooted it ( tip: show dhcp proxy and config dhcp proxy {enable | disable} from cli )
  2. with WebAuth, we use an external https auth page: with 4.2.176 it's disabled by default the SSLv2 support, the wism will use SSLv3, so some clients cannot see the auth page.. (the oldest browsers....) (tip: to enable SSLv2 with cli: config network secureweb cipher-option sslv2 enable )
  3. after an intensive troubleshooting, we found problems with the web authentication page. In fact, most of times with 4.2.176.0 the redirect to the external auth page doesn't work! After a lot of tries and debugs, we have created a .tar with our custom authentication page and uploading via tftp into each controller. (see instructions: http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008067489f.shtml#guide )
    To enable the new "Customized bundle" you must go in the "Wlan" - click on ssid - Security L3 - choose "Override global config", select the "Customized (Downloaded)" and choose "login.html". (see picture below ;-)




Interesting Links for troubleshooting web authentication on Wireless Lan Controllers:



NOTE: we still have problems with web auth redirects, seems to be an unofficial "bug" of the 4.2.176.0 and of the 5.2.157.0. (see: this educause.edu post and this one ). Maybe in the next weeks we'll decide to downgrade to 4.2.130.0 )

NOTE2: 30 mar 2009 we have made a DOWNGRADE to 4.2.130 version and solved the webauth login page problems.