MLPoFR (Multilink PPP over Frame Relay)
Frame Relay does not natively support features such as authentication,
link quality monitoring, and reliable transmission. By using PPP over Frame Relay these these features can be enabled. A useful feature of PPP that can be used over Frame Relay as well is PPP multilink: Multilink PPP over Frame Relay (MLPoFR).
Example Config.
Router 2
username R3 password 0 CISCO
interface Multilink1
ip address 174.1.23.2 255.255.255.0
ppp multilink
ppp multilink group 1
interface Serial2/0
no ip address
encapsulation frame-relay
serial restart-delay 0
no frame-relay inverse-arp
!
interface Serial2/0.203 multipoint
frame-relay interface-dlci 203 ppp Virtual-Template1
!
interface Serial2/0.213 multipoint
frame-relay interface-dlci 213 ppp Virtual-Template1
interface Virtual-Template1
no ip address
ppp authentication chap
ppp chap hostname Rack1R2
ppp multilink
ppp multilink group 1
Router 3
username R2 password 0 CISCO
interface Multilink1
ip address 174.1.23.3 255.255.255.0
ppp multilink
ppp multilink group 1
interface Serial2/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay interface-dlci 302 ppp Virtual-Template1
no frame-relay inverse-arp
!
interface Serial2/1
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay interface-dlci 312 ppp Virtual-Template1
no frame-relay inverse-arp
interface Virtual-Template1
no ip address
ppp authentication chap
ppp multilink
ppp multilink group 1
Saturday, November 29, 2008
Monday, November 24, 2008
Lock and Key ACL
A Lock and Key ACL is also known as a dynamic ACL. This feature effectively allows a router to control downstream access to other devices.
Once the user has authenticated to the router access is opened up according to the configured dynamic acl.
R3 ------ R2 ------R7
In this scenario telent access to R7 is prohibited by R2 until the user has authenticated to R2.
ip access-list extended RICH
dynamic TEST permit tcp any host 150.1.7.7 eq telnet
deny tcp any host 150.1.7.7 eq telnet
permit ip any any
lint vty 0 4
login local
username RICH pasword RICH
username RICH autocommand access-enable timeout 5
From R3 i try and telnet to R7.
R3#telnet 150.1.7.7
Trying 150.1.7.7 ...
% Destination unreachable; gateway or host down
I then telent to R2 first...
R3#telnet 150.1.2.2
Trying 150.1.2.2 ... Open
User Access Verification
Username: RICH
Password:
[Connection to 150.1.2.2 closed by foreign host]
Once authenticated to R2 controll is returned to R3 from where i can now telnet to R7.
R3#telnet 150.1.7.7
Trying 150.1.7.7 ... Open
Router_7>
On R2 i examine the access-list and can see the dynamic acl has been activated.
Extended IP access list RICH
10 Dynamic DYNAMIC permit tcp any any eq telnet
permit tcp any any eq telnet (6 matches) (time left 281)
20 deny tcp any host 150.1.7.7 eq telnet (45 matches)
30 permit ip any any (1005 matches)
N.B.
In a later lock and key scenario i encountered the extra requirement - Once authenticated the user alone should be the only one able to access the host via telnet. This was initially food for thought as with the configuration above access is opened up from 'any' source.
In fact to tie a dynamic access list down to the user in question the aoutocommand must include the 'host' keyword. i.e.
username RICH autocommand access-enable host timeout 1
N.B.B One further note the autocommand can be applied directly under the vty interface and thus applied to all vty logins.
live vty 0 4
autocommand access-enable host timeout 1
N.B.B.B!!! Whilst researching this i realised that the autocommand feature can be used to execute any command upon user login. For example
username RICH autocommand show ip interface brief
This works! Once the user has logged in, the interface status is displayed and then the user is logged out.
Filtering L2 Traffic
Mac access-lists can be used to match traffic by L2 characteristics. In turn this traffic can be forwarded or filtered using Vlan ACLs or VACLs.
For example key words available on a mac acl include the following
aarp EtherType: AppleTalk ARP
amber EtherType: DEC-Amber
appletalk EtherType: AppleTalk/EtherTalk
cos CoS value
dec-spanning EtherType: DEC-Spanning-Tree
decnet-iv EtherType: DECnet Phase IV
diagnostic EtherType: DEC-Diagnostic
dsm EtherType: DEC-DSM
etype-6000 EtherType: 0x6000
etype-8042 EtherType: 0x8042
lat EtherType: DEC-LAT
lavc-sca EtherType: DEC-LAVC-SCA
lsap LSAP value
mop-console EtherType: DEC-MOP Remote Console
mop-dump EtherType: DEC-MOP Dump
msdos EtherType: DEC-MSDOS
mumps EtherType: DEC-MUMPS
netbios EtherType: DEC-NETBIOS
vines-echo EtherType: VINES Echo
vines-ip EtherType: VINES IP
xns-idp EtherType: XNS IDP
By way of an example i will filter all DEC diagnostic traffic from VLAN 10...
mac access-list extended RICH
permit any any DEC-Diagnostic
vlan access-map TEST
match mac address RICH
action drop
vlan access-map TEST
action forward
vlan filter TEST vlan-list 10
For example key words available on a mac acl include the following
aarp EtherType: AppleTalk ARP
amber EtherType: DEC-Amber
appletalk EtherType: AppleTalk/EtherTalk
cos CoS value
dec-spanning EtherType: DEC-Spanning-Tree
decnet-iv EtherType: DECnet Phase IV
diagnostic EtherType: DEC-Diagnostic
dsm EtherType: DEC-DSM
etype-6000 EtherType: 0x6000
etype-8042 EtherType: 0x8042
lat EtherType: DEC-LAT
lavc-sca EtherType: DEC-LAVC-SCA
lsap LSAP value
mop-console EtherType: DEC-MOP Remote Console
mop-dump EtherType: DEC-MOP Dump
msdos EtherType: DEC-MSDOS
mumps EtherType: DEC-MUMPS
netbios EtherType: DEC-NETBIOS
vines-echo EtherType: VINES Echo
vines-ip EtherType: VINES IP
xns-idp EtherType: XNS IDP
By way of an example i will filter all DEC diagnostic traffic from VLAN 10...
mac access-list extended RICH
permit any any DEC-Diagnostic
vlan access-map TEST
match mac address RICH
action drop
vlan access-map TEST
action forward
vlan filter TEST vlan-list 10
MQC and Random Detect
To configure WRED in the MQC, one of two conditions must be met. There must either be a bandwidth reservation made within a class, or the default-class must be running weighted fair queuing.
Friday, November 21, 2008
Redistribution Gotcha
In the above scenario the loopback interface address is introduced into OSPF via the 'redistribute connected' command on router 3. Following this OSPF is redistributed into the RIP domain on router 3 using 'redistributed ospf 1 subnets metric 5'.
Upon examining the routing table on router 4 i was surprised to find no route for 150.1.3.3 present! This is to do with an anomoly with redistribution on the device performing the redistribution itself. When OSPF is redistributed into RIP it will carry all OSPF routes EXCEPT locally redistributed ones. In this instance RIP must pull such routes in explicitly using the 'redistribute connected' command itself.
Notes....
1)When redistributing in IPV6 it is also necessary to incorporate the 'redistribute connected' . Without this local interfaces are not redsitributed by default.
2) When redistributing rip into OSPF any route for directly connected interfaces ARE taken across by default. :-)!
3) With OSPF and EIGRP mutual redistribution connected routes are taken across by default.
Final note to self!!! With redistribution watch out for connected routes! particularly with RIP and IPV6.
Thursday, November 20, 2008
OSPF routing part VIII - Conditional default route
In the above scenario R3 must only advertise a default route to F4 if its connection to BB2 is up.
This can be achieved by making use of conditional default route advertisement feature. This requires use of a route-map to indicate those routes that must be available in the routing table before the default route will be advertised.
In his example
Rack1R3#show ip route inc 204.12C 204.12.1.0/24 is directly connected, FastEthernet1/0
ip prefix-list BB2 permit 204.12.1.0/24
route-map CONNECTED permit 10
match ip address prefix-list BB2
router ospf 1
default-information originate route-map CONNECTED
Once the config is applied on R3 the default route pops up on R4.
Rack1R4#sir inc 0.0.0
Gateway of last resort is 191.1.34.3 to network 0.0.0.0O*E2 0.0.0.0/0 [110/1] via 191.1.34.3, 00:16:22, Serial2/0
If i shut down the fa1/0 interface on R3 the default route 204.12.1.0/24 dissapears from the routing table on R3 and subsequently the default route dissappears from R4 routing table as well.
Wednesday, November 19, 2008
OSPF routing part VII - NSSA special case
Consider the following scenario whereby an NSSA area exists between router 2 and 7. As expected type 7 LSAs are allowed to flow from router 7 to router 2, into area 0. An additional requirement was imposed that router 7 must ONLY see a default route from router 2. This can be achieved by specifying a 'not so stubby totally stubby area'!
The issue with acheiving the lab requirements is that by default type 7 LSAs are allowed to flow in BOTH directions: i.e. router 2 <->router 7. To prevent the flow of type 7 LSAs from Router 2 the 'no-redistribution' option can be used
router 2
router ospf 1
area 27 nssa no-summary no-redistribution
Tuesday, November 18, 2008
Switchport port security
In this post i denote the config required to restrict access to port fa0/09 to 3 mac addresses only. In the event that further hosts try to connect a syslog message is generated.
interface FastEthernet0/09
switchport mode access
switchport port-security
switchport port-security maximum 4
switchport port-security violation restrict
switchport port-security mac-address 0040.7014.8ef0
switchport port-security mac-address 00d0.144e.07bf
switchport port-security mac-address 00e0.341c.7871
!
logging 134.1.8.100
To verify configuration use the 'show port-security' commands.
SW3#show port-security int fa0/09 address
Secure Mac Address Table
------------------------------------------------------------------------
Vlan Mac Address Type Ports Remaining Age
(mins)
---- ----------- ---- ----- -------------
1 0040.7014.bef0 SecureConfigured Fa0/10 -
1 00d0.144e.07bf SecureConfigured Fa0/10 -
1 00e0.341c.7871 SecureConfigured Fa0/10 -
------------------------------------------------------------------------
Total Addresses: 3
SW3#show port-security int fa0/09
Port Security : Enabled
Port Status : Secure-down
Violation Mode : Restrict
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 3
Total MAC Addresses : 3
Configured MAC Addresses : 3
Sticky MAC Addresses : 0
Last Source Address:Vlan : 0000.0000.0000:0
Security Violation Count : 0
interface FastEthernet0/09
switchport mode access
switchport port-security
switchport port-security maximum 4
switchport port-security violation restrict
switchport port-security mac-address 0040.7014.8ef0
switchport port-security mac-address 00d0.144e.07bf
switchport port-security mac-address 00e0.341c.7871
!
logging 134.1.8.100
To verify configuration use the 'show port-security' commands.
SW3#show port-security int fa0/09 address
Secure Mac Address Table
------------------------------------------------------------------------
Vlan Mac Address Type Ports Remaining Age
(mins)
---- ----------- ---- ----- -------------
1 0040.7014.bef0 SecureConfigured Fa0/10 -
1 00d0.144e.07bf SecureConfigured Fa0/10 -
1 00e0.341c.7871 SecureConfigured Fa0/10 -
------------------------------------------------------------------------
Total Addresses: 3
SW3#show port-security int fa0/09
Port Security : Enabled
Port Status : Secure-down
Violation Mode : Restrict
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 3
Total MAC Addresses : 3
Configured MAC Addresses : 3
Sticky MAC Addresses : 0
Last Source Address:Vlan : 0000.0000.0000:0
Security Violation Count : 0
Monday, November 17, 2008
DOT1Q Tunnelling
This feature allows a user trunk to be encapsulated in a tagged vlan across a service provider cloud. The switchport configuration is fairly straightforward.
1) Select a vlan that will be used to encapsulated and trunk the user traffic
2) Set up the service provider edge switch ports as dot1q tunnel ports
R4 --------- SW3 ----------------- SW4 ---------- R5
SW3
vlan 500
interface fastethernet 0/23
switchport access vlan 500
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
no cdp enable
SW4
vlan 500
interface fastethernet 0/23
switchport access vlan 500
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
no cdp enable
The user router ports are set as trunk ports e.g.
R4#s run begin interface Fast
interface FastEthernet0/0
no ip address
duplex full
!
interface FastEthernet0/0.4
encapsulation dot1Q 4
ip address 191.1.4.4 255.255.255.0
!
interface FastEthernet0/0.40
encapsulation dot1Q 40
ip address 191.1.40.4 255.255.255.0
!
interface FastEthernet0/0.45
encapsulation dot1Q 45
ip address 191.1.45.4 255.255.255.0
!
interface FastEthernet0/0.49
encapsulation dot1Q 49
ip address 191.1.49.4 255.255.255.0
R5#s run beg interface Fas
interface FastEthernet0/0
duplex full
!
interface FastEthernet0/0.45
encapsulation dot1Q 45
ip address 191.1.45.5 255.255.255.0
!
interface FastEthernet0/0.50
encapsulation dot1Q 50
ip address 191.1.50.5 255.255.255.0
!
interface FastEthernet0/0.59
encapsulation dot1Q 59
ip address 191.1.59.5 255.255.255.0!
N.B. 2 desirable commands when implementing a dot1q tunnel...
system mtu 1504 - ensures the exra 4 byte dot1q header is accomodated
vlan dot1q tag native - ensures there is no chance of confusion between customer and service provider untagged vlans.
N.B.B Having now revisited this blog some 5 months later i realise one assumption made here!! Of course VLAN 500 must be trunked between the SP switches!!
Wednesday, November 12, 2008
MQC - Shape vs Bandwidth Parameter
In this post i examine the difference between the MQC shape and bandwidth parameters. Often when applying a config to answer a lab question i find that i have made the incorrect choice in my selection, using one option, shape or bandwidth, when in fact the other was the required solution.
My confusion was cleared up when i found the following example on the doc cd.
Router(config)# policy-map shape-cbwfq
Router(config-pmap)# class cust1
Router(config-pmap-c)# shape average 384000
Router(config-pmap-c)# bandwidth 256
Router(config-pmap)# class cust2
Router(config-pmap-c)# shape peak 512000
Router(config-pmap-c)# bandwidth 384
Router(config-pmap-c)# configure terminal
In the above scenario both parameters, shape and bandwidth, were used at the same time! In reality this is because each parameter performs a different function.
In summary: bandwidth allocates a minimum bandwidth to the selected traffic flow, whereas shape enables the traffic flow to rise to the assigned throughput before throttling occurs. A subtle but explicitly different function.
Note to myself here, is to read carefully what the question requires. Use bandwidth to reserve throughput and shape to limit throughput.
My confusion was cleared up when i found the following example on the doc cd.
Router(config)# policy-map shape-cbwfq
Router(config-pmap)# class cust1
Router(config-pmap-c)# shape average 384000
Router(config-pmap-c)# bandwidth 256
Router(config-pmap)# class cust2
Router(config-pmap-c)# shape peak 512000
Router(config-pmap-c)# bandwidth 384
Router(config-pmap-c)# configure terminal
In the above scenario both parameters, shape and bandwidth, were used at the same time! In reality this is because each parameter performs a different function.
In summary: bandwidth allocates a minimum bandwidth to the selected traffic flow, whereas shape enables the traffic flow to rise to the assigned throughput before throttling occurs. A subtle but explicitly different function.
Note to myself here, is to read carefully what the question requires. Use bandwidth to reserve throughput and shape to limit throughput.
Frame Relay - TCP and RTP header compression
TCP or RTP compression can be used to increase efficiency of bandwidth utilisation on slow serial connections. It can be enabled on a per interface basis or simply on a per DLCI basis. Likewise if enabled on a physical interface it can then also be disabled on a per DLCI basis.
Configuration for RTP and TCP compression follows the same syntax. In this post i detail the steps necessary to enable RTP compression first on an interface and second just on a single DLCI.
First to enable on an interface.
config-if#ip rtp header-compression
or
config-if#ip rtp header-compression passive
In the first case header compression is applied to all packets, whereas in the later it is only applied to those packets that arrive with header compression already enabled.
Second to apply on a per DLCI basis
config-if#frame-relay map ip 162.1.0.3 403 rtp header-compression active connections 15
Documentation can be found on the DOC CD under the WAN Configuration section at
http://www.cisco.com/en/US/docs/ios/12_2/wan/configuration/guide/wcffrely_ps1835_TSD_Products_Configuration_Guide_Chapter.html#wp1002780
Configuration for RTP and TCP compression follows the same syntax. In this post i detail the steps necessary to enable RTP compression first on an interface and second just on a single DLCI.
First to enable on an interface.
config-if#ip rtp header-compression
or
config-if#ip rtp header-compression passive
In the first case header compression is applied to all packets, whereas in the later it is only applied to those packets that arrive with header compression already enabled.
Second to apply on a per DLCI basis
config-if#frame-relay map ip 162.1.0.3 403 rtp header-compression active connections 15
Documentation can be found on the DOC CD under the WAN Configuration section at
http://www.cisco.com/en/US/docs/ios/12_2/wan/configuration/guide/wcffrely_ps1835_TSD_Products_Configuration_Guide_Chapter.html#wp1002780
Tuesday, November 11, 2008
BGP Unsuppress Maps
Within BGP routes can be summarized using the 'aggregate-address' command. When the summary-only option is utilised all granular routes within the summary range are suppressed.
If a BGP neighbor requires some of the granular routes within the summary this can be achieved via use of the 'unsuppress-map' neighbor command.
Of note here!!! When defining the routes to be unsuppressed do NOT use an acl - this simply does not work in my experience. Use a prefix-list and all works as expected.
router bgp 100
aggregate-address 112.0.0.0 248.0.0.0 summary-only
neighbor 1.2.3.4 unsuppress-map R3
route-map R3
match ip address prefix-list R3
ip prefix-list R3 seq 10 permit 116.0.0.0/8
ip prefix-list R3 seq 15 permit 117.0.0.0/8
ip prefix-list R3 seq 20 permit 118.0.0.0/8
ip prefix-list R3 seq 25 permit 119.0.0.0/8
N.B.
An alternative to using the 'summary-only' key word on the aggregate-address command is via the 'suppress-map' option can be used to achieve the same net result.
e.g.
route-map SUPPRESS
router bgp 100
aggregate-address 112.0.0.0 248.0.0.0 suppress-map SUPPRESS
In summary routes can be suppressed on the aggregate-address command and unsupressed in a more garnular fashion with the neighbor commands.
If a BGP neighbor requires some of the granular routes within the summary this can be achieved via use of the 'unsuppress-map' neighbor command.
Of note here!!! When defining the routes to be unsuppressed do NOT use an acl - this simply does not work in my experience. Use a prefix-list and all works as expected.
router bgp 100
aggregate-address 112.0.0.0 248.0.0.0 summary-only
neighbor 1.2.3.4 unsuppress-map R3
route-map R3
match ip address prefix-list R3
ip prefix-list R3 seq 10 permit 116.0.0.0/8
ip prefix-list R3 seq 15 permit 117.0.0.0/8
ip prefix-list R3 seq 20 permit 118.0.0.0/8
ip prefix-list R3 seq 25 permit 119.0.0.0/8
N.B.
An alternative to using the 'summary-only' key word on the aggregate-address command is via the 'suppress-map' option can be used to achieve the same net result.
e.g.
route-map SUPPRESS
router bgp 100
aggregate-address 112.0.0.0 248.0.0.0 suppress-map SUPPRESS
In summary routes can be suppressed on the aggregate-address command and unsupressed in a more garnular fashion with the neighbor commands.
Friday, November 7, 2008
Multicast Routing - Selecting RPS
In this post i look at auto rp and how the mapping agent can be used to select specific RPs for specified groups.
This requires the use of the command ip pim rp-announce-filter on the mapping agent. The rp-announce filter needs to match the send-rp-announce
filter used by the RPs. If the groups requested by the RP do not match the mapping agent’s filters, non matching groups are discarded.
Example:
R1 (MAPPING AGENT)
interface Loopback0
ip pim sparse-dense-mode
!
ip pim send-rp-discovery Loopback0 scope 16
ip pim rp-announce-filter rp-list 1 group-list 2
!
access-list 1 permit 150.1.3.3
access-list 2 permit 239.0.0.0 0.255.255.255
R3 (CANDIDATE RP)
interface Loopback0
ip pim sparse-dense-mode
!
ip pim send-rp-announce Loopback0 scope 16 group-list 50
!
access-list 50 permit 239.0.0.0 0.255.255.255
post script.
If the rp-announce-filter does not match an rp then NO filtering is applied. That is for filtering to take place a positive match is first required on the RP within the RP list. Hence to filter RP multicast groups announced by an RP it is first necessary to match the RP and specify the allowed multicast groups. If the RP is denied in the RP list then NO filtering is applied!!
This requires the use of the command ip pim rp-announce-filter on the mapping agent. The rp-announce filter needs to match the send-rp-announce
filter used by the RPs. If the groups requested by the RP do not match the mapping agent’s filters, non matching groups are discarded.
Example:
R1 (MAPPING AGENT)
interface Loopback0
ip pim sparse-dense-mode
!
ip pim send-rp-discovery Loopback0 scope 16
ip pim rp-announce-filter rp-list 1 group-list 2
!
access-list 1 permit 150.1.3.3
access-list 2 permit 239.0.0.0 0.255.255.255
R3 (CANDIDATE RP)
interface Loopback0
ip pim sparse-dense-mode
!
ip pim send-rp-announce Loopback0 scope 16 group-list 50
!
access-list 50 permit 239.0.0.0 0.255.255.255
post script.
If the rp-announce-filter does not match an rp then NO filtering is applied. That is for filtering to take place a positive match is first required on the RP within the RP list. Hence to filter RP multicast groups announced by an RP it is first necessary to match the RP and specify the allowed multicast groups. If the RP is denied in the RP list then NO filtering is applied!!
Thursday, November 6, 2008
BGP Dampening
Enables BGP to suppress use and advertisement of routes that consistently flap.
Configured under the BGP routing protocol. Each time a route flaps a penalty of 1000 is applied to it. This value does NOT appear to be configurable. However the threshold at which routes are suppressed or unsuppressed is.
Suppress Limit: the value to start suppressing a route.
Reuse Limit: the value to start reusing a route.
Alongside these values its possible to
1) specify how quickly a routes penalty is reduced following a period of stability: this is termed 'half-life'.
2) specify the maximum suppression time for a route if it has been stable. This value kicks in if half life degradtion of a penalty takes 'too long'. For example a route may have a period of very high instability and incurr a high penalty - in this scenario it may take an inordinate time of stability to enable re-advertisement waiting for half-life degradation.
The config can simply be applied as follows if the default values will suffice:
bgp dampening
Default values are
penalty: 1000 (not configurable)
half life: 15 minutes
suppress limit: 2000
reuse limit: 750
max suppress: 4 * half life.
If there was a requirement to change half life to 30 minutes, and suppress limit to 3000, whilst leaving other parameters at default this can be achieved as follows:
R1(config-router)#bgp dampening 30 750 3000 120
R1#show ip bgp dampening para
dampening 30 750 3000 120
Half-life time : 30 mins Decay Time : 3600 secs
Max suppress penalty: 12000 Max suppress time: 120 mins
Suppress penalty : 3000 Reuse penalty : 750
You can apply dampening to specific routes by using a route-map to match the prefixes you want to apply dampening to.
First, create the prefix-lists to match the routes:
ip prefix-list RICH seq 5 permit 12.0.0.0/8
ip prefix-list RICH seq 10 permit 13.0.0.0/8
Then match them in the route-map and set the dampening parameters:
route-map DAMPEN permit 10
match ip address prefix-list RICH
set dampening 10 1000 2000 30
Finally, under the BGP process apply the route-map to the dampening command:
router bgp 100
bgp dampening route-map DAMPEN
This ensures that only the prefixes matched in the route-map have dampening applied to them.
Configured under the BGP routing protocol. Each time a route flaps a penalty of 1000 is applied to it. This value does NOT appear to be configurable. However the threshold at which routes are suppressed or unsuppressed is.
Suppress Limit: the value to start suppressing a route.
Reuse Limit: the value to start reusing a route.
Alongside these values its possible to
1) specify how quickly a routes penalty is reduced following a period of stability: this is termed 'half-life'.
2) specify the maximum suppression time for a route if it has been stable. This value kicks in if half life degradtion of a penalty takes 'too long'. For example a route may have a period of very high instability and incurr a high penalty - in this scenario it may take an inordinate time of stability to enable re-advertisement waiting for half-life degradation.
The config can simply be applied as follows if the default values will suffice:
bgp dampening
Default values are
penalty: 1000 (not configurable)
half life: 15 minutes
suppress limit: 2000
reuse limit: 750
max suppress: 4 * half life.
If there was a requirement to change half life to 30 minutes, and suppress limit to 3000, whilst leaving other parameters at default this can be achieved as follows:
R1(config-router)#bgp dampening 30 750 3000 120
R1#show ip bgp dampening para
dampening 30 750 3000 120
Half-life time : 30 mins Decay Time : 3600 secs
Max suppress penalty: 12000 Max suppress time: 120 mins
Suppress penalty : 3000 Reuse penalty : 750
You can apply dampening to specific routes by using a route-map to match the prefixes you want to apply dampening to.
First, create the prefix-lists to match the routes:
ip prefix-list RICH seq 5 permit 12.0.0.0/8
ip prefix-list RICH seq 10 permit 13.0.0.0/8
Then match them in the route-map and set the dampening parameters:
route-map DAMPEN permit 10
match ip address prefix-list RICH
set dampening 10 1000 2000 30
Finally, under the BGP process apply the route-map to the dampening command:
router bgp 100
bgp dampening route-map DAMPEN
This ensures that only the prefixes matched in the route-map have dampening applied to them.
Sunday, November 2, 2008
VRRP - Part 2 Object Tracking Using Metric
R2 and R3 are configured for VRRP on a shared LAN segment. R3 is the master unless its route to 13.0.0.0/24 disappears or its metric increases.
R3
interface FastEthernet0/0
ip address 10.0.0.3 255.255.255.0
duplex half
vrrp 1 ip 10.0.0.254
vrrp 1 priority 101
vrrp 1 authentication text RICH
Here is the route to 13.0.0./24
Router_3#s ip route 13.0.0.1
Routing entry for 13.0.0.0/24
Known via "ospf 1", distance 110, metric 61, type intra area
Last update from 12.0.0.5 on FastEthernet1/0, 00:12:32 ago
Routing Descriptor Blocks:
* 12.0.0.5, from 12.0.0.5, 00:12:32 ago, via FastEthernet1/0
Route metric is 61, traffic share count is 1
Note the OSPF metric is 61. For the purposes of tracking 61 i will mark as an UP metric and anything higher/worse will be considered DOWN.
track 10 ip route 13.0.0.0 255.255.255.0 metric threshold
threshold metric up 61 down 62
I introduce the tracking parameter to VRRP
interface FastEthernet0/0
vrrp 1 track 10
I know check the state of the tracked object
Router_3#s track 10
Track 10
IP route 13.0.0.0 255.255.255.0 metric threshold
Metric threshold is Up (OSPF/61/61)
4 changes, last change 00:16:34
Metric threshold down 62 up 61
First-hop interface is FastEthernet1/0
Tracked by:
VRRP FastEthernet0/0 1
The tracked object is marked UP and R3 remains the master!
Router_3#s vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Fa0/0 1 101 3605 Y Master 10.0.0.3 10.0.0.254
I now increase the metric of the 13.0.0.0 route by increasing the OSPF cost on neighboring router R5.
R5(config)#int fa1/0
R5(config-if)#ip ospf cost 200
R3 detects the metric has changed and decrements the priority by 10 (default) and the router now becomes the backup.
00:44:58: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Master -> Backup
Router_3#s vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Fa0/0 1 91 3605 Y Backup 10.0.0.2 10.0.0.254
Checking the tracking status again.
Router_3#s track 10
Track 10
IP route 13.0.0.0 255.255.255.0 metric threshold
Metric threshold is Down (OSPF/201/201) 5 changes, last change 00:02:08
Metric threshold down 62 up 61
First-hop interface is FastEthernet1/0
Tracked by:
VRRP FastEthernet0/0 1
VRRP - Part 1 Authentication
VRRP is a non-proprietary router redundancy protocol (as opposed to the CISCO proprietary HSRP) defined by RFC2338. The aim of boths protocols is to provide a redundant default gateway for hosts on the same subnet. This is achieved by enabling a virtual IP address that in effect both (or more) routers service.
On the DOC CD HSRP is found under 12.2 ip services. I found VRRP under 12.3 ip services.
http://www.cisco.com/en/US/docs/ios/12_0st/12_0st18/feature/guide/st_vrrpx.html
The good news as far as i can see is that vrrp config is almost identical to HSRP: just substitute vrrp keyword instead of the standby keyword.
In this example i make R2 and R3 vrrp partners
Router 2
interface fastethernet 0/0
vrrp 1 ip 10.0.0.254
Router 3
interface fastethernet 0/0
vrrp 1 ip 10.0.0.254
Router_3#s vrrp
FastEthernet0/0 - Group 1
State is Master
Virtual IP address is 10.0.0.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Master Router is 10.0.0.3 (local), priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec
Router_2#s vrrp
FastEthernet0/0 - Group 1
State is Backup
Virtual IP address is 10.0.0.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Master Router is 10.0.0.3, priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec (expires in 2.741 sec)
Unlike HSRP preemption comes pre enabled. VRRP has the concept of master and backup router as opposed to HSRPs active and standby.
Now to introduce authentication. This feature only allows plain text authentication, so in itself it is not really a security feature but rather a feature to prevent misconfigured hosts joing the group.
To enable
Router 1
interface fastethernet 0/0
vrrp 1 authentication text RICH
Router 3
interface fastethernet 0/0
vrrp 1 authentication text RICH
Now to review the vrrp status again
Router_2#s vrrp
FastEthernet0/0 - Group 1
State is Master
Virtual IP address is 10.0.0.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Authentication is enabled
Master Router is 10.0.0.2 (local), priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec
Subscribe to:
Posts (Atom)