Wednesday, September 17, 2008

ISCW Lab (and BSCI review )

NOTE: this is a ISCW lab only, it uses basic mpls setup, I agree that a real ISP will implement mpls vpn instead of direct routing the customers prefixes...

Well:
A new lab for practice ISCW arguments, thanks to Luca Moretti for partecipating.


Here the topology:




Scenario:
Acme Gmbh is a trading company that have a central office named "Hannover"(CON6 and CON7) and two branches (CON8 = branch "Bergamo" and CON11+CON1 = branch "Trento").
The connection between Hannover and Trento is made by a fastethernet connection with an ISP named "Majico Connecting World" ;-) (CON2 + CON3 + CON4) and have a redundant E1 (serial link) as backup link.

Goal of this lab:
-configure routing between branches and provider (see topology map) (backup serial link betw Hannover and Trento is a leased line, it costs much and have a traffic based bill, so be careful and use ISP as preferred route!)
-do not redistribute ISP internal routes to customers, but generate a default for each office using bgp
-loopbacks representing office lans and have to be routed with correct netmask
-configure basic mpls for ISP routers
-configure various tunnels to secure branches connections

...more tasks and configurations as soon as possible...

-(optional ONT refresh) configure QoS using nbar on link between CON7 and CON8 (both directions), assign the appropriate bandwidth values for Voip, sql, default and sacvenger (p2p, kazaa...) classes. CON8 (Trento) office has 15 ip Cisco 7940 with G.729 codec.
-(optional ONT refresh 2) configure QoS on CON11 to minimize bandwidth waste due to peer-to-peer traffic

Solution config parts:

1) routing:

CON11#
router ospf 1
router-id 172.16.99.11
log-adjacency-changes
passive-interface default
no passive-interface FastEthernet0/0
no passive-interface Tunnel0
network 172.17.1.2 0.0.0.0 area 15
network 192.168.0.0 0.0.0.3 area 15 !-- this network is used for tunneling..
!
router bgp 64815
no synchronization
bgp log-neighbor-changes
redistribute ospf 1 match internal
neighbor 172.16.0.22 remote-as 65000
neighbor 172.17.1.1 remote-as 64815
neighbor 172.17.1.1 next-hop-self !-- Next-hop-self for neighbour CON1, because CON1 don't have a route to the link betw CON11 and CON2
no auto-summary

One of the most difficult task was the use of ISP between CON7 and CON8 instead of backup serial link... because CON7 and 8 use the same BGP as ...

CON8#
router bgp 64814
no synchronization
bgp log-neighbor-changes
redistribute ospf 1
neighbor 172.16.0.1 remote-as 65000
neighbor 172.16.0.1 allowas-in 1 !-- this allows prefixes with the same as in path (here 64814), 1 means 1 recursion allowed
neighbor 172.16.0.1 route-map LAN-via-ISP in !--route map to set weight
neighbor 172.17.1.6 remote-as 64814
no auto-summary
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
ip access-list extended LAN-CON7 !-- matches internal lan of CON7 and CON6
permit ip 10.2.0.0 0.0.0.255 any
permit ip 10.3.0.0 0.0.0.255 any
!
!
route-map LAN-via-ISP permit 10
match ip address LAN-CON7
set weight 35500 !-- the weight for locally generated routes is 32768, so a value of 35500 is preferred and prefixes inserted into routing table


the same for CON7, modify access-list prefixes (and bgp neighbour) only.

Thursday, September 11, 2008

Configuring a Cisco Adsl router acting as PPTP CLIENT

At work we have a PPTP Access Server for remote dial-in users.
Why PPTP? Because it's very easy to configure for users, and don't require any software installation on win Pcs....

Well at home for me it's a bit annoying to bring up the pptp connection every time I need and set-up static routes on my pc... so I realized that my poor outdated Cisco 827 maybe can act as PPTP client.

First I tryed to find how configure it, but CLIENT configuration for PPTP is unusual, I only have found this document: http://groups.google.com/group/comp.dcom.sys.cisco/msg/81d58c31469d558b
and a page with mppe on Cisco site (it was a "new feature" on IOS 12.0):
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5c/pptp.htm

well, tryed and it works, so I adapted to my requirements:
  • use the normal ADSL as default route
  • use PPTP only to reach specified private/public networks of my workplace


The final and explained config is HERE [+/-]



!
service internal !---> necessary to enable VPDN to allow a request-dialin group to be part of a rotary group or dialer pool.

!
no ip gratuitous-arps !---> recommended
!
vpdn enable
!
vpdn-group 2
request-dialin
protocol pptp !--> recent Ioses doesn't have pptp support... try "protocol ? " too see..
rotary-group 2 !---> Lol! we're now members of Rotay Club? ;-)) no! is the dialer-group specification for vpdn..
initiate-to ip A.B.C.D !---> A.B.C.D is the ip of my pptp Access Server
!
!
interface ATM0
no ip address
no ip mroute-cache
atm ilmi-keepalive
bundle-enable
dsl operating-mode auto
hold-queue 224 in
pvc 8/35
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
!
interface Dialer0
description ADSL-side Dialer
ip address negotiated
ip access-group 101 in
ip mtu 1492
ip nat outside
ip inspect autosec_inspect out
encapsulation ppp
ip tcp adjust-mss 542
dialer pool 1
no cdp enable
ppp chap hostname yourhostname
ppp chap password yourpassword
!
interface Dialer2 !---> why dialer2 and not 1 ... don't know this time I like #2 ;-)
description PPTP-side Dialer
ip address negotiated
ip access-group 102 in
ip nat outside
encapsulation ppp
dialer in-band
dialer idle-timeout 0 !---> PPTP is slow to negotiate and start, so better an infinite timeout... (this doesn't affect negotiation time, but forces the dialer interface after connection to stay "always up" regardless of interesting traffic)
dialer string 123 !---> seems to be ignored so.. senseless string
dialer vpdn
dialer-group 2 !---> Remember Rotary? see dialer-list 2 below
no cdp enable
ppp pfc local forbid !---> do not perform compression locally
ppp pfc remote reject !---> reject remote compression proposals
ppp encrypt mppe auto !---> mppe = Micro$oft Point-to-Point Encryption (128bit max) You MUST have a "k9" IOS image to perform encryption, as usual
ppp chap hostname your-pptp-username !---> use username@domain if your pptp server is a Micro$oft Isa server, Alex Pronin has experienced that domain\username isn't understood
ppp chap password your-pptp-password
!
ip nat inside source list 111 interface Dialer0 overload !---> NAT for ADSL-exit
ip nat inside source list 110 interface Dialer2 overload !---> NAT for PPTP-exit, you will share your pptp-assigned ip inside your private lan
!
ip classless !---> recommended if you will apply static routes correctly
ip route 0.0.0.0 0.0.0.0 Dialer0 !---> Default route to ADSL
ip route 172.16.0.0 255.255.0.0 Dialer2 !---> some private routes to PPTP
ip route 172.17.0.0 255.255.0.0 Dialer2
ip route 172.18.0.0 255.255.0.0 Dialer2
ip route 192.168.206.0 255.255.255.0 Dialer2
ip route 192.168.236.0 255.255.255.0 Dialer2
ip route A.B.C.0 255.255.255.0 Dialer2 !---> if you want to route the public class of pptp access server though the pptp (un)secure connection,
ip route A.B.C.D 255.255.255.255 Dialer0 !---> you must route the access server out to ADSL, and the full public class through pptp (LONGEST BIT MATCH will do the rest ;-)
!
!
access-list 101 permit !---> Place your ADSL-side permit Here
access-list 101 deny ip any any
!
access-list 102 permit !---> Place your PPTP-side permit Here
access-list 102 deny ip any any
!
!---> Acl101: used for PPTP NAT
access-list 110 deny ip any host A.B.C.D !----> no nat for your Access Server (maybe unnecessary)
access-list 110 permit ip any A.B.C.0 0.0.0.255 !----> NAT for the rest of Access Server C Class
access-list 110 permit ip any 192.168.206.0 0.0.0.255 !----> NAT for the statically routed classes thorugh pptp tunnel
access-list 110 permit ip any 192.168.236.0 0.0.0.255
access-list 110 permit ip any 172.16.0.0 0.0.255.255
access-list 110 permit ip any 172.17.0.0 0.0.255.255
access-list 110 permit ip any 172.18.0.0 0.0.255.255
access-list 110 deny ip any any
!
!---> Acl111: used for ADSL NAT
access-list 111 permit ip any host A.B.C.D !----> NAT for your Access Server
access-list 111 deny ip any A.B.C.0 0.0.0.255 !----> no NAT for the rest of Access Server C Class
access-list 111 deny ip any 192.168.206.0 0.0.0.255 !----> NAT for the statically routed private classes
access-list 111 deny ip any 192.168.236.0 0.0.0.255
access-list 111 deny ip any 172.16.0.0 0.0.255.255
access-list 111 deny ip any 172.17.0.0 0.0.255.255
access-list 111 deny ip any 172.18.0.0 0.0.255.255
access-list 111 permit ip any

dialer-list 2 protocol ip permit !<---- used to initiate the pptp tunnel, permit all traffic, the acl110 will permit/block in more depth


Note that the interface dialer2, when up, is in "spoofing" state:

Majico#sh int dialer 2
Dialer2 is up (spoofing), line protocol is up (spoofing)
Hardware is Unknown
Internet address is 10.31.206.10/32
MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec,
reliability 255/255, txload 4/255, rxload 40/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
....
here "spoofing" means "listening" for interesting traffic, defined with the dialer-list 2 .
Some useful commands to monitor vpdn status are:
Majico#sh vpdn

%No active L2TP tunnels

%No active L2F tunnels

PPTP Tunnel and Session Information Total tunnels 1 sessions 1

LocID Remote Name State Remote Address Port Sessions VPDN Group
4 A.B.C.D estabd A.B.C.D 1723 1 2

LocID RemID TunID Intf Username State Last Chg Uniq ID
4 22144 4 Vi3 estabd 05:52:17 n/a

here we see the Virtual-Access interface assigned to pptp dialer, and
Majico#sh ppp mppe virtual-Access 3
Interface Virtual-Access3 (current connection)
Software encryption, 128 bit encryption, Stateless mode
packets encrypted = 17155 packets decrypted = 22828
sent CCP resets = 0 receive CCP resets = 0
next tx coherency = 771 next rx coherency = 2348
tx key changes = 17155 rx key changes = 22828
rx pkt dropped = 0 rx out of order pkt= 0
rx missed packets = 0

to see encryption statistics and type of encryption performed by mppe (we have configured "auto" negotiation, remember?)

Thanks to Dan Lanciani for configuration review!

Tuesday, September 2, 2008

Today's work in a shot: cleaning switches after 5 years of continuous service

Today is "tha cleaning day": i cleaned about 15 3550/3500XL inline power and 2 2970.
The 3550s where in production for about 5 years without cleaning or power off...







Inside's dirt...



...and the full stack cleaned and stored

Well... incredible, only one 3550 has a failed fan, all the others still (noisly a bit) working ;-)
For cleaning i used a small portable air compressor and a 150h stud. (thanks Franz)