Cisco 3560 switches ondersteunen geen service-policy output, in plaats daarvan moet er met srr-queue bandwidth limit x gewerkt worden. Dit commando werkt met een percentage van de actuele fysieke snelheid van de interface, met als ondergrens 10%. Er wordt echt gekeken naar de fysieke snelheid, het bandwidth x commando heeft hier dus geen invloed op. Dit houdt in dat je op een 1000Mbit link niet lager kunt “knijpen” dan 100Mbit.

Nou zou je natuurlijk de interfacesnelheid vast op 10Mbit Full Duplex kunnen zetten en de klant vriendelijk verzoeken hetzelfde te doen. Echter is dat in mijn opzicht vragen om problemen.

De oplossing

Op Cisco Catalyst switches is het mogelijk om te specificeren welke snelheden er tijdens het auto-negotiation proces geadverteerd moeten worden. Wanneer de klantapparatuur ook op auto/auto staat,  zal deze gaan onderhandelen met de Cisco switch.  Deze zal op zijn beurt aangeven bijvoorbeeld alleen maar 10Mbit te ondersteunen. De klantapparatuur weet niet beter en zal die snelheid dan ook accepteren.   Zie ook hieronder:

c3560(config-if)#speed auto ?
10    Include 10 Mbps in auto-negotiation advertisement
100   Include 100 Mbps in auto-negotiation advertisement
1000  Include 1000 Mbps in auto-negotiation advertisement
<cr>

c3560#show run | b 0/1
interface GigabitEthernet0/1
switchport mode access
speed auto 10
srr-queue bandwidth limit 50
!
C3560#sh int status

Port      Name               Status       Vlan       Duplex  Speed Type
Gi0/1                        connected    1          a-full   a-10 10/100/1000BaseTX

Het srr-queue bandwidth limit 50 is nu 50% van 10Mbit en zodoende dus de gewenste 5Mbit. Op deze manier kan er dus toch op 5Mbit “geknepen” worden, terwijl de Hakketoekietec™ apparatuur mooi op auto/auto blijft staan. Vergeet het globale mls qos commando overings niet op te nemen in je configuratie voor het “aanzetten” van QoS.

AMS-IX

DE-CIX

Bij onze zuiderburen heeft het dus wel degelijk een stijging weten te veroorzaken, bij ons in NL niet. Het doel van IPv6 dag is logischerwijs niet het generen van extra verkeer, maar testen wat er “stuk” gaat wanneer diensten ook via IPv6 aangeboden gaan worden. Des al niet te min is het wel leuk om te zien…

Om mijn “collega engineers” op gang te helpen heb ik destijds onderstaande configuratie als voorbeeld geschreven. In dit voorbeeld zijn er twee site-to-site tunnels geconfigureerd, waarbij de eerste tunnel gebruik maakt van 3DES encryptie en de tweede gebruik maakt van AES.

ip access-list extended ACL-CRYPTOMAP-FA01-10
permit ip 192.168.1.0 0.0.0.255 192.168.10.0 0.0.0.255

ip access-list extended ACL-CRYPTOMAP-FA01-20
permit ip 192.168.1.0 0.0.0.255 192.168.20.0 0.0.0.255

ip access-list extended ACL-NAT
deny ip 192.168.1.0 0.0.0.255 192.168.10.0 0.0.0.255
deny ip 192.168.1.0 0.0.0.255 192.168.20.0 0.0.0.255
permit ip 192.168.1.0 0.0.0.255 any

crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
lifetime 28800

crypto isakmp policy 20
encr aes
authentication pre-share
group 2
lifetime 28800

crypto isakmp key AAAAAAAAA address 1.1.1.1 no-xauth
crypto isakmp key BBBBBBBBB address 2.2.2.2 no-xauth

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha-hmac

crypto map CRYPTOMAP-FA01 10 ipsec-isakmp
set peer 1.1.1.1
set pfs group2
set transform-set ESP-3DES-SHA
match address ACL-CRYPTOMAP-FA01-10

crypto map CRYPTOMAP-FA01 20 ipsec-isakmp
set peer 2.2.2.2
set pfs group2
set transform-set ESP-AES-SHA
match address ACL-CRYPTOMAP-FA01-20

interface Fa0/1
ip address 6.6.6.1 255.255.255.252
ip nat outside
crypto map CRYPTOMAP-FA01

interface Fa0/0
ip address 192.168.1.254 255.255.255.0
ip nat inside

ip nat inside source list ACL-NAT interface Fa0/1 overload

Wat in bovenstaande configuratie niet meegenomen is, is het het feit dat IPSEC extra overhead met zich meebrengt. De MTU van ethernet is standaard 1500 bytes. Daar waar Path MTU Discovery (PMTUD) helaas vaak zijn werk niet goed kan doen doordat ICMP ten onrechte geblokkeerd wordt, is er “MSS clamping” als workaround bedacht. Hiermee forceert de router dat “de andere kant” niet de MTU waarde zal overschrijden en dat er zodoende geen fragmentatie plaats zal vinden.

Standaard binnen IOS is deze waarde 1460 bytes (Ethernet MTU – IP en TCP overhead). Echter is dat voor IPSEC verbindingen niet afdoende, daar waar er dan ook nog IPSEC overhead overheen komt. Cisco ASA’s hanteren hierom bijvoorbeeld standaard ook een TCPMSS waarde van 1380. Bij IOS zal dit door de engineer zelf aangepast moeten worden onder de desbetreffende interface met het “ip tcp adjust-mss” commando. De exacte maximale waarde die gebruikt kan worden is afhankelijk van de gekozen encryptie.

De volgende aliassen kent een Cisco Catalyst 2960 standaard:

alias exec h help
alias exec lo logout
alias exec p ping
alias exec r resume
alias exec s show
alias exec u undebug
alias exec un undebug
alias exec w where

Het aanmaken van een eigen alias gaat als volgt:

c2960# conf t
c2960(config)#alias exec SID show interfaces description
c2960(config)#^Z
c2960#SID
Interface Status Protocol Description
Vl1 up up
Vl254 up up
Gi0/1 up up
Gi0/2 down down

FW01(config)# policy-map global_policy
FW01(config-pmap)# class class-default
FW01(config-pmap-c)# set connection decrement-ttl

Bij een DHCP reservation gebruikt de client nog steeds DHCP maar is deze ervan verzekerd dat hij altijd hetzelfde IP adres krijgt van de DHCP server. De DHCP server bepaald dit aan de hand van het Client-ID.

Allereerst zal het Client-ID achterhaald moeten worden van de client waarvoor er een reservation aangemaakt dient te worden. De gemakkelijkste manier om dit te doen is door een algemene DHCP pool/scope te configureren en de client daar een IP adres uit te laten opvragen. Zie onderstaand voorbeeld voor de configuratie van zo’n pool.

R1(config)#ip dhcp pool VLAN10
R1(dhcp-config)#network 172.16.10.0 255.255.255.0
R1(dhcp-config)#default-router 172.16.10.254
R1(dhcp-config)#lease 0 8 0

Wanneer de client eenmaal een IP adres “geclaimed” heeft is deze lease terug te vinden in de DHCP bindings.

R1#show ip dhcp binding
Bindings from all pools not associated with VRF:

IP address	Client-ID/	Lease expiration	Type
	Hardware address/
	User name
172.16.10.1	0063.6973.636f.2d63.	Mar 01 2002	Automatic
	6330.312e.3065.3434.
	2e30.3030.302d.566c.
	3130

Nu het Client-ID bekend is kan er een pool aangemaakt worden speciaal voor deze client.

R1(config)#ip dhcp pool VLAN10-CLIENT1
R1(dhcp-config)#host 172.16.10.1
R1(dhcp-config)#client-identifier 0063.6973.636f.2d63.6330.312e.3065.3434.2e30.3030.302d.566c.3130
R1(dhcp-config)#default-router 172.16.10.254

Het IP adres is nu gereserveerd voor de client, wat ook zichtbaar is in de DHCP bindings van de router.

R1#show ip dhcp binding
Bindings from all pools not associated with VRF:

IP address	Client-ID/	Lease expiration	Type
	Hardware address/
	User name
172.16.10.1	0063.6973.636f.2d63.	Infinite	Manual
	6330.312e.3065.3434.
	2e30.3030.302d.566c.
	3130

Het probleem is dat wanneer je de duplex instelling aanpast, de link in zijn geheel niet terugkeert omdat de speed nog niet vast geconfigureerd is. Natuurlijk heb je voor je de change gebruik gemaakt van het “reload in 5″ commando, dus keert de switch na 5 minuten weer terug online met de oude instellingen (Zo niet, een tip voor de volgende keer ).

Echter is de geplande change nog steeds niet uitgevoerd en om hier nou speciaal voor naar het datacenter toe te rijden…

De sleutel tot succes is het schrijven van een macro, hiermee kun je namelijk een hele reeks configuratie aan een stuk op de achtergrond laten doorvoeren. Dat je ssh sessie bij het uitvoeren van de macro wegvalt maakt dan niet uit, de macro loopt wel door . Om bovenstaand voorbeeld te nemen zou je de volgende configuratie kunnen gebruiken:

c3560#copy run start
Destination filename [startup-config]?
Building configuration…
[OK]
c3560#reload in 5
Reload scheduled in 4 minutes and 56 seconds
Proceed with reload? [confirm]
c3560(config)#macro name CHANGE
Enter macro commands one per line. End with the character ‘@’.
interface fastethernet 0/1
shutdown
speed 100
duplex full
no shut
@
c3560(config)#macro global apply CHANGE

Mocht bovenstaande alsnog onsuccesvol zijn zal de geplande reload niet geannuleerd worden en zal de switch dus opnieuw opstarten met de recent opgeslagen configuratie .

Update
In IOS 12.2-55 wordt het macro name commando niet meer weergegeven via IOS help, echter is dit nog wel steeds de manier om een macro te definiëren!

c3560(config)#macro ?
auto Macro autoexecution settings
global Enter global macro configuration
c3560(config)#macro name ?
% Unrecognized command
c3560(config)#macro name TEST
Enter macro commands one per line. End with the character ‘@’.

Bovenstaand kan gerealiseerd worden door het WAN IP adres, wat anders direct op de dialer interface gezet zou worden, op de interface van het WAN VLAN te configureren. Door vervolgens het adres met ip unnumbered ook weer op de Dialer te zetten hoeft er geen apart IP netwerk gemaakt te worden.  Op zich is hier niets spannends aan, maar wat als er geen machine aangesloten is op het WAN VLAN?

Netwerkdiagram

Nat configuratie

interface Vlan2
ip nat inside
!
interface Dialer1
ip nat outside
!
ip nat inside source list ACL-NAT interface vlan1 overload
ip access-list ACL-NAT
permit ip 10.0.0.0 0.0.0.255 any

Terugkomend op bovenstaande vraag is het noodzakelijk om te weten hoe VLAN interfaces werken. Een vlan interface is fysiek namelijk altijd up, maar laag twee (protocol) zal down blijven zolang er geen apparatuur aangesloten is. Dit betekend dat het verkeer vanuit het LAN naar het internet niet genat kan worden in deze situatie.

R1#show ip int brief

Interface  IP-Address    OK?  Method   Status    Protocol
Vlan1        80.1.1.1       YES  manual    up            down
Vlan2        10.0.0.254   YES  manual    up             up
Dialer1       80.1.1.1      YES  TFTP      up             up

R1#debug ip nat
R1# Nov 7 01:50:04.611: NAT: translation failed (A), dropping packet s=10.0.0.1 d=70.0.0.254
R1# Nov 7 01:50:04.691: NAT: translation failed (A), dropping packet s=10.0.0.1 d=70.0.0.254

Dit gedrag kan uitgezet worden door “autostate” uit te schakelen, hierdoor zal de VLAN interface op laag twee ook “up” komen of er nu apparatuur aangesloten is of niet.

R1(config)#interface vlan1
R1(config-if)#no autostate

R1#show ip int brief

Interface  IP-Address    OK?  Method   Status    Protocol
Vlan1        80.1.1.1       YES  manual    up            up
Vlan2        10.0.0.254   YES  manual    up             up
Dialer1       80.1.1.1      YES  TFTP      up             up

R1#debug ip nat

R1# Nov  7 01:55:44.499: NAT*: s=10.0.0.1->70.0.0.100, d=80.0.0.254 [8699]
R1# Nov  7 01:55:44.583: NAT*: s=80.1.1.254, d=70.0.0.100->10.0.0.1 [8699]

De natting (PAT) van het LAN verkeer naar het internet gaat nu dus goed!

Complete configuratie

interface FastEthernet0/0
no ip address
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface FastEthernet1/0
description *** LAN ***
switchport access vlan 2
!
interface Vlan1
description *** WAN ***
ip address 80.1.1.1 255.255.255.248
ip virtual-reassembly
ip tcp adjust-mss 1452
no autostate
!
interface Vlan2
description *** LAN ***
ip address 10.0.0.254 255.255.255.0
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1452
!
interface Dialer1
mtu 1492
ip unnumbered vlan 1
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip nat inside source list ACL-NAT interface vlan1 overload
!
ip access-list ACL-NAT
permit ip 10.0.0.0 0.0.0.255 any