Archive for December, 2008

Notes

Posted by Peter Kurdziel on December 31, 2008

I’ve been updating older NOTES threads but this blog does not push them to the front page.

http://usaccie.wordpress.com/2008/12/27/irdp-notes/

http://usaccie.wordpress.com/2008/12/27/odr-notes/

http://usaccie.wordpress.com/2008/12/26/frame-relay-notes/

http://usaccie.wordpress.com/2008/12/17/eigrp-notes/

http://usaccie.wordpress.com/2008/12/12/rip-notes/

http://usaccie.wordpress.com/2008/11/07/ospf-notes/

http://usaccie.wordpress.com/2008/11/06/bgp-notes/

Posted in BGP, EIGRP, FRAME-RELAY, IRDP, ODR, OSPF, RIP, Routing & Switching Lab | Leave a Comment »

The difference between redistribute connected and redistribute connected subnets

Posted by Peter Kurdziel on December 31, 2008

The difference between redistribute connected and redistribute connected subnets
r4
router ospf 1
redistribute connected

R3(config-router)#do sho ip route os
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/65] via 131.1.34.4, 00:00:02, Serial1/0.34

==== now lets try redistribute connected subnets ====
r4
router ospf 1
redistribute connected subnets

R3(config-router)#do sho ip route os
4.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O       4.4.4.4/32 [110/65] via 131.1.34.4, 00:00:12, Serial1/0.34
O E2    4.4.0.0/24 [110/20] via 131.1.34.4, 00:00:03, Serial1/0.34
O E2    4.4.1.0/24 [110/20] via 131.1.34.4, 00:00:03, Serial1/0.34
O E2    4.4.2.0/24 [110/20] via 131.1.34.4, 00:00:03, Serial1/0.34
O E2    4.4.3.0/24 [110/20] via 131.1.34.4, 00:00:03, Serial1/0.34

Posted in OSPF, Routing & Switching Lab | 1 Comment »

BGP: peer is filtering routes. no access to peer.

Posted by Peter Kurdziel on December 29, 2008

You are peered with a router that you do not have access to. The peer is filtering incoming routes via a peer group or community. What can you do to make sure the route is advertised to the peer.

On the edge router:

ip prefix-list FORCEROUTE seq 5 permit 192.168.1.151/32

route-map OURNET2YOURNET perm 10

match ip add prefix-list FORCEROUTE

router bgp 65000

neighbor 10.1.1.60 remote-as 65111

neighbor 10.1.1.60 next-hop-self

neighbor 10.1.1.60 send-community

neighbor 10.1.1.60 route-map OURNET2YOURNET in

Posted in BGP, Routing & Switching Lab | Leave a Comment »

IE beta lab1

Posted by Peter Kurdziel on December 28, 2008

review:

Enable a special TCP feature in R1 that allows avoiding so-called “silly window syndrome”

service nagle

—————————

Limit the time required by R2 to wait for a TCP connection establishment to the minimum

ip tcp synwait-time 5

———————————–

Create a new user named “ADMIN” in R1 with the password value of “CISCO” and privilege level 7.
The use should be allowed to execute any of OSPF debugging commands.
Allow the user to selectively disable any debugging commands enabled on the router.
The user should be allowed to change any IP settings on any interface in the router.
Additionally the user should be allowed to change any SNMP settings and execute any SNMP show commands.
Configure so that the user can see all allowed commands in running configuration as well.

Username ADMIN privilege 7 password 0 CISCO privilege interface all level 7 ip privilege configure all level 7 snmp-server privilege configure level 7 interface privilege exec level 7 configure terminal privilege exec all level 7 undebug privilege exec all level 7 show snmp privilege exec level 7 show running-config privilege exec all level 7 debug ip ospf

—————————————————-

DDoS Attack Protection 0/3

Configure R2 to protect servers on VLAN33 from SYN flooding attacks coming from behind BB2.
Intercept connections as they pass through to the servers and terminate sessions after 30 seconds of inactivity.
Allow for maximum of 400 semi-established connections and drop their number down to 200 when the threshold is crossed.
Do not allow creating more than 30 half-open connection per minute on average.
Start dropping the half-open connections once they cross the connection-rate threshold and until the average rate is 20 per minute.

This is a type of assertion with the following parameters;

Rack4R2(tcl)#show running-config | inc tcp intercept ip tcp intercept list 133 ip tcp intercept ip tcp intercept ip tcp intercept ip tcp intercept ip tcp intercept

This is a type of assertion with the following parameters;
Rack4R2(tcl)#regexp {ip tcp intercept list\s+(\d+)} [exec "show running-config | inc tcp intercept"] -> acl ; puts [exec "show ip access-list $acl"] Extended IP access list 133 10 permit ip

Posted in Routing & Switching Lab | Leave a Comment »

IRDP notes

Posted by Peter Kurdziel on December 27, 2008

IRDP notes

config r1 & r2 to advertise the ip address of their e0/0 int as a

default gateway to r3. If r1 goes down then r2 should be used.
keep advertisements for 5 seconds, max interval 5 sec, min interval 3

sec. do not use static routes, HSRP, VRRP or GLBP.

r3
no ip routing
ip gdp irdp

r1&r2
int e0/0
no ip proxy-arp

r3
clear arp

r1
int e0/0
ip irdp
ip irdp hold 5
ip irdp max 5
ip irdp min 3
ip irdp preference 100

r2
int e0/0
ip irdp
ip irdp hold 5
ip irdp max 5
ip irdp min 3
ip irdp pref 90

show ip irdp e0/0
debug ip icmp
debug ip pack
debug ip pack det

Posted in FHRP, IRDP, Routing & Switching Lab | 1 Comment »

ODR notes

Posted by Peter Kurdziel on December 27, 2008

On demand routing – ODR
note: ODR needs CDP to function. If you have to disable cdp look into IRDP.

once you have your FR set up enable ODR on the hub.

config t
router ODR

Gateway of last resort is not set

C    1.0.0.0/8 is directly connected, Loopback0
o    4.0.0.0/8 [160/1] via 10.1.14.4, 00:00:13, Serial1/0.14
10.0.0.0/24 is subnetted, 2 subnets
C       10.1.14.0 is directly connected, Serial1/0.14
C       10.1.13.0 is directly connected, Serial1/0.13
———————————————————

Posted in ODR, Routing & Switching Lab | Leave a Comment »

Frame-relay notes

Posted by Peter Kurdziel on December 26, 2008

Frame-relay

config fr to use 2 pipes and 1 ip address on both r1 and r2.

int mult 12
ip address 10.1.1.1 255.255.255.0

int virtual-template 12
ppp multi group 12

int s1/0
en frame
frame-relay interface-dlci 102 ppp virtual-template 12
no shut

int s1/1
en frame
frame-relay interface-dlci 201 virtual-template 12
no shut

sho ppp multilink
——————————————————–

no frame switch

int s1/1
ip add 10.1.1.1 255.255.255.0
no keepalives <—————— on both sides
clock rate 64000 <————— on DCE
frame-relay map ip 10.1.1.3 113

sh frame lmi <——there are no LMI’s since keepalives are disabled.
——————————————————–

usefull commands
clear frame-relay in
sh frame map
sh frame pvc
sh frame lmi
debug ip packet
debug frame-relay packet
debug fram lmi
—————————–

to config a router as a frame switch
(DCE)
conf t
frame switching
int s1/0
clock rate 64000
frame-relay intf-type dce

frame-relay intf-type

To configure a Frame Relay switch type, use the frame-relay intf-type

command in interface configuration mode. To disable the switch, use the

no form of this command.

frame-relay intf-type [dce | dte | nni]

no frame-relay intf-type [dce | dte | nni]
Syntax Description

dce
(Optional) Router or access server functions as a switch connected to a

router.

dte
(Optional) Router or access server is connected to a Frame Relay network.

nni

(Optional) Router or access server functions as a switch connected to a

switch—supports Network-to-Network Interface (NNI) connections.

Usage Guidelines
This command can be used only if Frame Relay switching has previously

been enabled globally by means of the frame-relay switching command.
————- ——————

when routing OSPF over frame-relay physical/multi

int s1/0
frame-relay map ip 150.1.100.1 401 broadcast < —— make sure you add

the BROADCAST keyword.
———————————-

config the router so the LMI status messages (keepalives) are sent every

5 seconds and Full status LMUI requests are send every 4 cycles instead

of 6

int s1/0
keepalive 5
frame-relay lmi-n391dte 4
———————————

frame-relay lmi-n391dte

To set a full status polling interval, use the frame-relay lmi-n391dte

command in interface configuration mode. To restore the default interval

value, assuming that a Local Management Interface (LMI) has been

configured, use the no form of this command.

frame-relay lmi-n391dte keep-exchanges

no frame-relay lmi-n391dte keep-exchanges

Syntax Description
keep-exchanges = Number of keep exchanges to be done before requesting a

full status message. Acceptable value is a positive integer in the range

from 1 to 255.

Usage Guidelines
Use this command when the interface is configured as data terminal

equipment (DTE) or a Network-to-Network Interface (NNI) as a means of

setting the full status message polling interval.
Examples

In the following example, one out of every four status inquiries

generated will request a full status response from the switch. The other

three status inquiries will request keepalive exchanges only.

interface serial 0
frame-relay intf-type DTE
frame-relay lmi-n391dte 4

————————–
frame-relay lmi-n392dce

To set the DCE and the Network-to-Network Interface (NNI) error

threshold, use the frame-relay lmi-n392dce command in interface

configuration mode. To remove the current setting, use the no form of

this command.

frame-relay lmi-n392dce threshold

no frame-relay lmi-n392dce threshold
Syntax Description
threshold= Error threshold value. Acceptable value is a positive integer

in the range from 1 to 10.

Usage Guidelines

In Cisco’s implementation, N392 errors must occur within the number

defined by the N393 event count in order for the link to be declared

down. Therefore, the threshold value for this command must be less than

the count value defined in the frame-relay lmi-n393dce command.
Examples

The following example sets the LMI failure threshold to 3. The router

acts as a Frame Relay DCE or NNI switch.

interface serial 0
frame-relay intf-type DCE
frame-relay lmi-n392dce 3
———————————

frame-relay lmi-n392dte

To set the error threshold on a DTE or network-to-network interface (NNI)

interface, use the frame-relay lmi-n392dte command in interface

configuration mode. To remove the current setting, use the no form of

this command.

frame-relay lmi-n392dte threshold
no frame-relay lmi-n392dte threshold

Syntax Description
threshold =
Error threshold value. Acceptable value is a positive integer in the

range from 1 to 10.

Examples

The following example sets the Local Management Interface (LMI) failure

threshold to 3. The router acts as a Frame Relay DTE or NNI switch.

interface serial 0
frame-relay intf-type DTE
frame-relay lmi-n392dte 3
——————————-

frame-relay lmi-n393dce

To set the DCE and Network-to-Network Interface (NNI) monitored events

count, use the frame-relay lmi-n393dce command in interface configuration

mode. To remove the current setting, use the no form of this command.

frame-relay lmi-n393dce events
no frame-relay lmi-n393dce events

Syntax Description
events =
Value of monitored events count. Acceptable value is a positive integer

in the range from 1 to 10.

Defaults
2 events

Usage Guidelines
This command and the frame-relay lmi-n392dce command define the condition

that causes the link to be declared down. In Cisco’s implementation, N392

errors must occur within the events argument count in order for the link

to be declared down. Therefore, the events value defined in this command

must be greater than the threshold value defined in the frame-relay lmi-

n392dce command.

Examples
The following example sets the Local Management Interface (LMI) monitored

events count to 3. The router acts as a Frame Relay DCE or NNI switch.

interface serial 0
frame-relay intf-type DCE
frame-relay lmi-n393dce 3
——————————-

frame-relay lmi-n393dte

To set the monitored event count on a DTE or Network-to-Network Interface

(NNI) interface, use the frame-relay lmi-n393dte command in interface

configuration mode. To remove the current setting, use the no form of

this command.

frame-relay lmi-n393dte events
no frame-relay lmi-n393dte events

Syntax Description
events =Value of monitored events count. Acceptable value is a positive

integer in the range from 1 to 10.

Defaults
4 events

Examples
The following example sets the Local Management Interface (LMI) monitored

events count to 3. The router acts as a Frame Relay DTE or NNI switch.

interface serial 0
frame-relay intf-type DTE
frame-relay lmi-n393dte 3
—————————–

frame-relay lmi-t392dce

To set the polling verification timer on a DCE or Network-to-Network

Interface (NNI) interface, use the frame-relay lmi-t392dce command in

interface configuration mode. To remove the current setting, use the no

form of this command.

frame-relay lmi-t392dce seconds
no frame-relay lmi-t392dce seconds

Syntax Description

seconds =Polling verification timer value from 5 to 30 seconds.

Defaults
15 seconds

Usage Guidelines
The value for the timer must be greater than the DTE or NNI keepalive

timer.

Examples
The following example indicates a polling verification timer on a DCE or

NNI interface set to 20 seconds:

interface serial 3
frame-relay intf-type DCE
frame-relay lmi-t392dce 20
————————-

frame-erlay point-to point
note: no need for no frame-relay inverse -arp since the interface is

point to point ( only 1 other router connects to our interface) .

int s1/0
encap frame
no shut
int s1/0.21 point-to-point
ip add 175.1.1.1 255.255.255.0
frame-relay interface-dlci 102
note: frame-relay map ip x.x.x.x 102 will kick back an error – you can

not use the frame-relay map command.
——————————————

frame-relay over multipoint and point-to- point
r1

int s1/0
en frame
no frame-relay inverse-arp
no shut

int s1/0.123 multipoint
ip add 123.1.1.1 255.255.255.0
frame-relay map ip 123.1.1.1 102
frame-relay map ip 123.1.1.2 102
frame-relay map ip 123.1.1.3 103

r2
interface Serial1/0
no ip address
encapsulation frame-relay
no dce-terminal-timing-enable

interface Serial1/0.21 point-to-point
ip address 150.1.123.2 255.255.255.0
frame-relay interface-dlci 201

r3
interface Serial1/0
ip address 150.1.123.3 255.255.255.0
encapsulation frame-relay
no dce-terminal-timing-enable
frame-relay map ip 123.1.1.1 301
frame-relay map ip 123.1.1.2 301
frame-relay map ip 123.1.1.3 301
no frame-relay inverse-arp

——————————————-

frame-relay without frame-relay mapping

int s1/0
encap frame
frame-relay interface-dlco 102 ppp virtual-template 1

int virtual-template 1
ip address 10.1.1.1 255.255.255.0
———————————————–

frame-relay and authentication
r1 and r2:
r1 should send a challenge when it’s called by r2. see ****
r2 should NOT authenticate when it’s called.
pass cisco
this authentication should be successfull even if the router’s name is

changed. see @@@@

r1
username r2 pass 0 cisco
int s1/0.12
no ip add
frame-rel interface-dlci 102 ppp virtual-template 12

int virtual-template 12
ip add 10.1.10.1 255.255.255.0
ppp authen chap callin ****
ppp chap hostname R1 @@@@

r2
username r1 pass 0 cisco

int s1/0.21
no ip add
frame-re interface-dl 201 ppp virtual-template 21

int virtual-template 21
ip add 10.1.10.2 255.255.255.0
ppp chap hostname R2 @@@@
————————————–

frame-relay and authentication
R1 <> R3
r1 should not authenticate when called.
r3 should use PAP authentication when its called by R1
pass cisco13
hostname SHOULD be used for this authentication

r1
int s1/0.13
no ip add
frame-re interface-dl 103 ppp virtual-template 13

int virtual-template 13
ip address 10.1.13.1 255.255.255.0
ppp pap sent-username r1 pass 0 cisco13

r3
username r1 pass 0 cisco13
inte s1/0.31
no ip add
frame-relay interface-dlci 301 ppp virtual-template 31

int virtual-template 31
ip add 10.1.13.3 255.255.255.0
ppp authentication pap callin
================================

r1<>r4
r1 should send a challenge when its called by r4 SEE ****
r4 should use pap authenticaton when its called by r1 SEE @@@@
pass for CHAP is ciscoCHAP SEE #####
for PAP = ciscoPAP & the hostname should be configured R1-PAP. SEE %%%%

NOTE: don’t forget to add the username!!

r1
username r4 pass ciscoCHAP ####
int s1/0.14
no ip add
frame-relay interface-dlci 104 ppp virtual-template 14

int virtual-template 14
ip add 10.1.14.1 255.255.255.0
ppp authentication chap callin ****
ppp pap sent-username R1-PAP password 0 ciscoPAP %%%%

r4
username R1-PAP password 0 ciscoPAP %%%%
username r1 password 0 ciscoCHAP ####

int s1/0.14
no ip add
frame-relay interface-dlci 401 ppp virtual 41

int virtual-template 41
ip add 10.1.14.4 255.255.255.0
ppp authen pap callin @@@@
———————————————————

Frame-relay end to end keepalives
–configure on both ends

conf t
map-class frame-relay EEK
frame-relay end-to-end keepalive mode bidirectional

int s1/0.12
frame-relay interface-dlci 102
class EEK

To verify: sho frame end-to keep inter s1/0.12
——————————-

config EEK between R1<>R4 for 3 errors in 5 events teh subinterface

should transition to a down state. After 4 sucessfules events in a row

the interface should come back up. Keepalives should be exchanged every

20 seconds.

r1
map-class frame-realy EEK14
frame-relay end keep mode bidirectonal
frame-relay end keep error-threshold recv 3
frame-relay end keep error-threshold send 3
frame-relay end keep event-windows recv 5
frame-relay end keep event-windows send 5
frame-relay end keep success-events recv 4
frame-relay end keep success-events send 4
frame-relay end keep timers recv 20
frame-relay end keep timers send 20
int s1/0.14
frame-relay interface-dlci 104
class EEK14
————————————–

Frame-relay unnumbered

r1(config-if)#frame-relay interface-dlci 102 ppp virtual-Template 1
%vtemplate error; failed to set up PPP-FR circuit <—- this is because I

had parts of an old config where I deleted Virtual-Template1 by doing no

Virtual-Template1 but Virtual-Access1 was left behind in the config. The

SOLUTION is to either create Virtual-Template1 first or create a

differnet Virtual-Template like Virtual-Template10.

R1 (hub)

int loop0
ip add 1.1.1.1 255.0.0.0

int s1/0
en frame
frame interface-dl 102 ppp virtual-template1
frame interface-dl 103 ppp virtual-template1
frame interface-dl 104 ppp virtual-template1

int virtual-template 1
ip unnumbered

r2 (spoke)

int loop0
ip add 2.2.2.2 255.0.0.0

int s1/0
en frame
frame interface-dl 201 ppp virtual-template2

int virtual-template 2
ip unnumbered

NOTE: PPP created a host route. sho ip route 2.0.0.0/32 <– to disable

this use NO PEER NEIGHBOR-ROUTE

Problem: the hub can ping the spokes. But the spokes can only ping the

hub and not any of the spokes.
solutuon: PBR

ip local policy route-map PINGSPOKES
route-map PINGSPOKES per 10
set ip next-hop 1.1.1.1
route-map PINGSPOKES per 20

—————————————————–

Posted in FRAME-RELAY, Routing & Switching Lab | Leave a Comment »

timers active-time

Posted by Peter Kurdziel on December 22, 2008

timers active-time

To adjust routing wait time, use the timers active-time command in router configuration mode. To disable this function, use the no form of the command.

timers active-time [time-limit | disabled]

no timers active-time

Syntax Description


time-limit	(Optional) Enhanced Interior Gateway Routing Protocol (EIGRP) active-time limit (in minutes). The time range is from 1 to 4294967295.
disabled	(Optional) Disables the timers and permits the routing wait time to remain active indefinitely.

Defaults

This command is disabled by default.

Command Modes

Router configuration

Command History


Release	Modification
10.0	This command was introduced.
12.4(6)T	Support for IPv6 was added.
12.2(33)SRB	This command was integrated into Cisco IOS Release 12.2(33)SRB.
12.2SX	This command is supported in the Cisco IOS Release 12.2SX train. Support in a specific 12.2SX release of this train depends on your feature set, platform, and platform hardware.

Usage Guidelines

In EIGRP, there are timers that control the time the router waits (after sending a query) before declaring the route to be in the stuck in active (SIA) state.

Examples

In the following example, the routing wait time is 200 minutes on the specified route:

router eigrp 5

 timers active-time 200

In the following example, the routing wait time is indefinite on the specified route:

router eigrp 5

 timers active-time disabled

In the following example, the routing wait time is 100 minutes on the specified route:

ipv6 router eigrp 1

 timers active-time 100

Posted in EIGRP, Routing & Switching Lab | Leave a Comment »

variance (EIGRP)

Posted by Peter Kurdziel on December 22, 2008

variance (EIGRP)

To control load balancing in an internetwork based on the Enhanced Interior Gateway Routing Protocol (EIGRP), use the variance command in router configuration mode. To reset the variance to the default value, use the no form of this command.

variance multiplier

no variance

Syntax Description


multiplier	Metric value used for load balancing. It can be a value from 1 to 128. The default is 1, which means equal-cost load balancing.

Defaults

1 (equal-cost load balancing)

Command Modes

Router configuration

Command History


Release	Modification
10.0	This command was introduced.
12.4(6)T	Support for IPv6 was added.
12.2(33)SRB	This command was integrated into Cisco IOS Release 12.2(33)SRB.
12.2SX	This command is supported in the Cisco IOS Release 12.2SX train. Support in a specific 12.2SX release of this train depends on your feature set, platform, and platform hardware.

Usage Guidelines

Setting a variance value enables EIGRP to install multiple loop-free routes with unequal cost in a local routing table. A route learned through EIGRP must meet two criteria to be installed in the local routing table:

•The route must be loop- free. This condition is satisfied when the reported distance is less than the total distance or when the route is a feasible successor.

•The metric of the route must be lower than the metric of the best route (the successor) multiplied by the variance configured on the router.

Thus, if the variance is set to 1, only routes with the same metric as the successor are installed in the local routing table. If the variance is set to 2, any EIGRP-learned route with a metric less than 2 times the successor metric will be installed in the local routing table.

Note EIGRP does not load-share between multiple routes; it only installs the routes in the local routing table. Then, the local routing table enables switching hardware or software to load-share between the multiple paths.

Examples

The following example sets a variance value of 4:

router eigrp 109

 variance 4

The following example sets a variance value of 2:

ipv6 router eigrp 11

 variance 2

Posted in EIGRP, Routing & Switching Lab | Leave a Comment »

ip summary-address eigrp as-number ip-address mask [admin-distance] [leak-map name]

Posted by Peter Kurdziel on December 22, 2008

ip summary-address eigrp

To configure a summary aggregate address for a specified interface, use the ip summary-address eigrp command in interface configuration mode. To disable a configuration, use the no form of this command.

ip summary-address eigrp as-number ip-address mask [admin-distance] [leak-map name]

no ip summary-address eigrp as-number ip-address mask

Syntax Description


as-number	Autonomous system number.
ip-address	Summary IP address to apply to an interface.
mask	Subnet mask.
admin-distance	(Optional) Administrative distance. A value from 0 to 255.
leak-map name	(Optional) Route-map reference to configure route leaking through the summary.

Defaults

•An administrative distance of 5 is applied to Enhanced Interior Gateway Routing Protocol (EIGRP) summary routes.

•EIGRP automatically summarizes to the network level, even for a single host route.

•No summary addresses are predefined.

•The default administrative distance metric for EIGRP is 90.

Command Modes

Interface configuration

Command History


Release	Modification
10.0	This command was introduced.
12.0(7)T	The admin-distance argument was introduced.
12.3(14)T	The leak-map keyword was introduced.
12.2(33)SRA	This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2SX	This command is supported in the Cisco IOS Release 12.2SX train. Support in a specific 12.2SX release of this train depends on your feature set, platform, and platform hardware.

Usage Guidelines

The ip summary-address eigrp command is used to configure interface-level address summarization. EIGRP summary routes are given an administrative distance value of 5. The administrative distance metric is used to advertise a summary without installing it in the routing table.

By default, EIGRP summarizes subnet routes to the network level. The no auto-summary command can be entered to configure subnet level summarization.

EIGRP Support for Leaking Routes

Configuring the leak-map keyword allows to advertise a component route that would otherwise be suppressed by the manual summary. Any component subset of the summary can be leaked. A route map and access list must be defined to source the leaked route.

The following is default behavior if an incomplete configuration is entered:

•If the leak-map keyword is configured to reference a nonexistent route map, the configuration of this keyword has no effect. The summary address is advertised but all component routes are suppressed.

•If the leak-map keyword is configured but the access-list does not exist or the route map does not reference the access list, the summary address and all component routes are sent.

Examples

The following example configures an administrative distance of 95 on interface Ethernet 0/0 for the 192.168.0.0/16 summary address:

Router(config)# router eigrp 1

Router(config-router)# no auto-summary

Router(config-router)# exit

Router(config)# interface Ethernet 0/0

Router(config-if)# ip summary-address eigrp 1 192.168.0.0 255.255.0.0 95

The following example configures the 10.1.1.0/24 subnet to be leaked through the 10.0.0.0 summary address:

Router(config)# router eigrp 1

Router(config-router)# exit

Router(config)# access-list 1 permit 10.1.1.0 0.0.0.255

Router(config)# route-map LEAK-10-1-1 permit 10

Router(config-route-map)# match ip address 1

Router(config-route-map)# exit

Router(config)# interface Serial 0/0

Router(config-if)# ip summary-address eigrp 1 10.0.0.0 255.0.0.0 leak-map LEAK-10-1-1

Router(config-if)# end

Posted in EIGRP, Routing & Switching Lab | Leave a Comment »

« Previous Entries

Limitless

Catagories

Global visitors

US visitors

Blogroll

CCIE lab sudy links

Tools

Meta

Cloud

Archive for December, 2008

timers active-time

Syntax Description

Defaults

Command Modes

Command History

Usage Guidelines

Examples

variance (EIGRP)

Syntax Description

Defaults

Command Modes

Command History

Usage Guidelines

Examples

ip summary-address eigrp

Syntax Description

Defaults

Command Modes

Command History

Usage Guidelines

Examples

Follow “Pete's Packet”