From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Thu Jul 17 2008 - 00:16:02 ART
Guys,
just to complement what Victor said, remember that CBAC feature has built-in
TCP interception feature. And it's always watch mode. The unique thing about
CBAC is that you can set maximum half-open TCP sessions count per-host, and
set up so-called "block-time" which prevent any traffic (even legitimate) to
attacked host for the duration of time specified.
Here are the TCP intercept setting for CBAC:
Rack1R1(config)# ip inspect max-incomplete high <number>
Rack1R1(config)# ip inspect max-incomplete low <number>
Rack1R1(config)# ip inspect one-minute high <number>
Rack1R1(config)# ip inspect one-minute low <number>
The next line is for per-host settings and block-time:
Rack1R1(config)# ip inspect tcp max-incomplete host number block-time
<minutes>
Note that interception feature is always on, as soon as you apply an inspect
rule to an interface.
-- Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice) petr@internetworkexpert.comInternetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 Outside US: 775-826-4344 Online Community: http://www.IEOC.com CCIE Blog: http://blog.internetworkexpert.com
2008/7/16 Victor Cappuccio <vcappuccio@gmail.com>:
> Hi Cisco Addicted, for your last question about the TCP intercept > > this feature implements software to protect TCP servers from TCP > SYN-flooding attacks, which are a type of denial-of-service attack > > by > > http://www.cert.org/tech_tips/denial_of_service.html > > A "denial-of-service" attack is characterized by an explicit attempt by > attackers to prevent legitimate users of a service from using that service. > Examples include > > * attempts to "flood" a network, thereby preventing legitimate network > traffic > * attempts to disrupt connections between two machines, thereby preventing > access to a service > * attempts to prevent a particular individual from accessing a service > * attempts to disrupt service to a specific system or person > > so lets do a DOS :P "just 4 education purpose" > > Having this topology > > R2 R1 R4 BB2 > | > R5 > > R2#traceroute 212.2.12.254 > > Type escape sequence to abort. > Tracing the route to 212.2.12.254 > > 1 192.168.12.1 0 msec 0 msec 4 msec > 2 192.168.134.4 28 msec 32 msec 28 msec > 3 212.2.12.254 28 msec * 28 msec > R2# > > R5#traceroute 212.2.12.254 > > Type escape sequence to abort. > Tracing the route to 212.2.12.254 > > 1 192.168.45.4 28 msec 28 msec 28 msec > 2 * > 212.2.12.254 28 msec * > R5# > > R1#conf ter > Enter configuration commands, one per line. End with CNTL/Z. > R1(config)#do show ip int brief | ex una > Interface IP-Address OK? Method Status > Protocol > FastEthernet0/0 192.168.173.1 YES NVRAM up > up > Serial0/0/0 192.168.134.1 YES manual up > up > Serial0/0/1 192.168.12.1 YES NVRAM up > up > Loopback0 110.110.1.1 YES NVRAM up > up > R1(config)# > > So the packets in R1 goes like this > > *Aug 3 21:53:58.896: IP: s=212.2.12.254 (Serial0/0/0), d=192.168.12.0 > (Serial0/0/1), g=192.168.12.0, len 100, forward > > lets modify a little bit the process > > R1#conf ter > Enter configuration commands, one per line. End with CNTL/Z. > R1(config)#int s0/0/1 > R1(config-if)#ip nat in > R1(config-if)#exit > *Aug 3 21:39:00.928: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, > changed state to up > R1(config)#int s0/0/0 > R1(config-if)#ip nat out > R1(config-if)#exit > R1(config)#ip nat inside source static 192.168.12.0 192.168.45.5 > R1(config)# > *Aug 3 22:01:05.580: ipnat_add_static_cfg: id 6, flag 6 > *Aug 3 22:01:05.580: id 6, flags 0, domain 0, lookup 0, from_addr > C0A80C00, > from_mask FFFFFFFF, from_port 0, to_addr C0A82D05, to_port 0 to_mask > FFFFFFFF, > proto 0 > *Aug 3 22:01:05.600: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, > 10) > [8516] > *Aug 3 22:01:05.600: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, > 10) > [8516] > *Aug 3 22:01:05.600: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254 > [8516] > R1(config)# > *Aug 3 22:01:07.596: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, > 10) > [8517] > *Aug 3 22:01:07.596: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254 > [8517] > R1(config)#do u > *Aug 3 22:01:09.596: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, > 10) > [8518] > *Aug 3 22:01:09.596: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254 > [8518] > R1(config)#do u all > All possible debugging has been turned off > R1(config)# > > So we are now translating the thing :) > > Now BB2 thinks that the thing comes from R5 > > *Aug 3 22:36:29.904: IP: tableid=0, s=192.168.45.5 (FastEthernet0/0), > d=212.2.12.254 (FastEthernet0/0), routed via RIB > *Aug 3 22:36:29.904: IP: s=192.168.45.5 (FastEthernet0/0), d=212.2.12.254 > (FastEthernet0/0), len 100, rcvd 3 > *Aug 3 22:36:29.904: IP: tableid=0, s=212.2.12.254 (local), d= > 192.168.45.5 > (FastEthernet0/0), routed via FIB > *Aug 3 22:36:29.904: IP: s=212.2.12.254 (local), d=192.168.45.5 > (FastEthernet0/0), len 100, sending > BB2# > > hehehe > > now lets configure the TCP intercept to see how it works > > again in this cisco link > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur > _c/scprt3/scddenl.htm<http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt3/scddenl.htm> > > A SYN-flooding attack occurs when a hacker floods a server with a barrage > of > requests for connection. Because these messages have unreachable return > addresses, the connections cannot be established. The resulting volume of > unresolved open connections eventually overwhelms the server and can cause > it > to deny service to valid requests, thereby preventing legitimate users from > connecting to a web site, accessing e-mail, using FTP service, and so on. > > Page 27 http://www.faqs.org/rfcs/rfc793.html > > The synchronization requires each side to send it's own initial > sequence number and to receive a confirmation of it in acknowledgment > from the other side. Each side must also receive the other side's > initial sequence number and send a confirming acknowledgment. > > 1) A > B SYN my sequence number is X > 2) A < B ACK your sequence number is X > 3) A < B SYN my sequence number is Y > 4) A > B ACK your sequence number is Y > > so lets try this on R2, BB1 and see what is the deal > > BB2#debug ip tcp pac > TCP Packet debugging is on > BB2# > rack8>2 > [Resuming connection 2 to R2 ... ] > > R2#telnet 212.2.12.254 > Trying 212.2.12.254 > rack8>11 > [Resuming connection 11 to bb2 ... ] > > *Aug 3 22:40:28.852: tcp0: I LISTEN 192.168.45.5:17199 212.2.12.254:23seq > 1721243964 > OPTS 4 SYN WIN 4128 > *Aug 3 22:40:28.852: tcp0: O SYNRCVD 192.168.45.5:17199 212.2.12.254:23seq > 1347870184 > OPTS 4 ACK 1721243965 SYN WIN 4128 > *Aug 3 22:40:28.884: tcp0: I SYNRCVD 192.168.45.5:17199 212.2.12.254:23seq > 1721243965 > RST WIN 0 > BB2# > *Aug 3 22:40:30.852: tcp0: I LISTEN 192.168.45.5:17199 212.2.12.254:23seq > 1721243964 > OPTS 4 SYN WIN 4128 > *Aug 3 22:40:30.852: tcp0: O SYNRCVD 192.168.45.5:17199 212.2.12.254:23seq > 1849125975 > OPTS 4 ACK 1721243965 SYN WIN 4128 > *Aug 3 22:40:30.880: tcp0: I SYNRCVD 192.168.45.5:17199 212.2.12.254:23seq > 1721243965 > RST WIN 0 > BB2# > rack8> > > So BB3 thinks that I comes from R5 :S > > So lets configure R4 with this access-list > > ip tcp intercept list 102 > ip tcp intercept watch-timeout 15 > ip tcp intercept mode watch > access-list 102 permit tcp any 212.2.12.0 0.0.0.255 > > R4#show tcp intercept statistics > Watching new connections using access-list 102 > 1 incomplete, 0 established connections (total 1) > 2 connection requests per minute > R4# > *Aug 3 22:13:40.019: INTERCEPT: server packet passed in SYNRCVD > (192.168.45.5:55622 <- 212.2.12.254:23) > *Aug 3 22:13:41.019: INTERCEPT: SYNRCVD timing out (192.168.45.5:55622<-> > 212.2.12.254:23) > *Aug 3 22:13:41.019: INTERCEPT(*): (192.168.45.5:55622 RST -> > 212.2.12.254:23) > > or we can modify watch time to see the thing faster :) > > R4#conf ter > Enter configuration commands, one per line. End with CNTL/Z. > R4(config)#no ip tcp intercept watch-timeout 15 > R4(config)#ip tcp intercept watch-timeout 5 > command accepted, interfaces with mls configured might cause inconsistent > behavior > > R4(config)#^Z > R4#show run > *Aug 3 22:15:21.359: %SYS-5-CONFIG_I: Configured from console by console > R4#show run | in intercept > ip tcp intercept list 102 > ip tcp intercept watch-timeout 5 > ip tcp intercept mode watch > R4# > rack8>2 > [Resuming connection 2 to R2 ... ] > > % Connection timed out; remote host not responding > > R2# > R2#telnet 212.2.12.254 > Trying 212.2.12.254 > rack8>4 > [Resuming connection 4 to R4 ... ] > > R4# > R4# > *Aug 3 22:15:33.727: INTERCEPT: new connection (192.168.45.5:46993 SYN -> > 212.2.12.254:23) > *Aug 3 22:15:33.731: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN > 212.2.12.254:23) > R4#show run | in inter > *Aug 3 22:15:35.727: INTERCEPT: server packet passed in SYNRCVD > (192.168.45.5:46993 <- 212.2.12.254:23) > R4#show tcp intercept connections > Incomplete: > Client Server State Create Timeout Mode > > Established: > Client Server State Create Timeout Mode > R4# > *Aug 3 22:15:38.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993<-> > 212.2.12.254:23) > *Aug 3 22:15:38.727: INTERCEPT(*): (192.168.45.5:46993 RST -> > 212.2.12.254:23) > *Aug 3 22:15:39.727: INTERCEPT: new connection (192.168.45.5:46993 SYN -> > 212.2.12.254:23) > R4# > *Aug 3 22:15:39.727: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN > 212.2.12.254:23) > R4#show tcp intercept connections > Incomplete: > Client Server State Create Timeout Mode > 192.168.45.5:46993 212.2.12.254:23 SYNRCVD 00:00:03 00:00:01 W > > Established: > Client Server State Create Timeout Mode > R4# > *Aug 3 22:15:44.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993<-> > 212.2.12.254:23) > *Aug 3 22:15:44.727: INTERCEPT(*): (192.168.45.5:46993 RST -> > 212.2.12.254:23) > R4# > *Aug 3 22:15:47.727: INTERCEPT: new connection (192.168.45.5:46993 SYN -> > 212.2.12.254:23) > *Aug 3 22:15:47.727: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN > 212.2.12.254:23) > R4# > *Aug 3 22:15:52.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993<-> > 212.2.12.254:23) > *Aug 3 22:15:52.727: INTERCEPT(*): (192.168.45.5:46993 RST -> > 212.2.12.254:23) > > Enjoy > Victor Cappuccio > > > On Tue, Jul 15, 2008 at 9:35 PM, Igor Manassypov <imanassypov@rogers.com> > wrote: > > they usually say something like 'passively watch traffic' > > > > Cisco Addicted <cisco.addicted@gmail.com> wrote: Dears, > > > > I have some confusion about the TCP intercept mode, I understand the > > difference between the two modes, but don't know one to use this in the > lab. > > I mean what will be the keywords to use specific mode (intercept | > watch)??? > > > > > > > > Thanks gangs. > > > > > > > > > > > > > > > > From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com] > > Sent: Tuesday, July 15, 2008 9:54 PM > > To: Jonathan Greenwood II > > Cc: Cisco Addicted; Peter Stephan; Nate Cielieska; Igor Manassypov; GS > > CCIE-Lab > > Subject: Re: rip passive int with neighbor command > > > > > > > > Actually there is another important point to be added onto this. EIGRP > only > > uses multicast to discover neighbors and for periodic keepalives. The > > actual exchange of the topology table is done through unicast. This > means > > that by default EIGRP actually uses multicast AND unicast, but if you use > > the neighbor statement it uses JUST unicast. The fact that the neighbor > > statement suppresses the multicast hello/keepalive implies that any other > > neighbors on the segment also need to unicast their hellos/keepalives, > > otherwise they will never discover each other. You can see this > operation > > in action if you "debug ip packet detail". Take the following case with > R1 > > having the address 10.0.0.1 and forming adjacency with the neighbor > > 10.0.0.2. > > > > R1 initializes its EIGRP process. > > > > R1#config t > > Enter configuration commands, one per line. End with CNTL/Z. > > R1(config)#router eigrp 1 > > R1(config-router)#no auto-summary > > R1(config-router)#network 0.0.0.0 > > R1(config-router)#end > > R1# > > > > Hellos are multicast out all links running EIGRP. > > > > Jul 15 11:39:54.695: IP: s=10.0.0.1 (local), d=224.0.0.10(FastEthernet0/0), > > len 60, sending broad/multicast, proto=88 > > Jul 15 11:39:54.699: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), > len > > 60, sending broad/multicast, proto=88 > > Jul 15 11:39:54.699: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, > rcvd > > 2, proto=88 > > > > A hello packet comes in from 10.0.0.2 via multicast and neighbor > adjacency > > occurs. > > > > Jul 15 11:39:54.707: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len > 60, > > rcvd 2, proto=88 > > Jul 15 11:39:54.711: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.0.2 > > (FastEthernet0/0) is up: new adjacency > > > > The topology is exchanged via unicast. > > > > Jul 15 11:39:54.711: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d= > 10.0.0.1 > > (FastEthernet0/0), routed via RIB > > Jul 15 11:39:54.711: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1 > > (FastEthernet0/0), len 40, rcvd 3, proto=88 > > Jul 15 11:39:54.715: IP: s=10.0.0.1 (local), d=224.0.0.10(FastEthernet0/0), > > len 60, sending broad/multicast, proto=88 > > Jul 15 11:39:54.719: IP: s=10.0.0.1 (local), d=10.0.0.2(FastEthernet0/0), > > len 40, sending, proto=88 > > Jul 15 11:39:54.719: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len > 77, > > rcvd 2, proto=88 > > Jul 15 11:39:54.723: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len > 69, > > rcvd 2, proto=88 > > Jul 15 11:39:54.727: IP: s=10.0.0.1 (local), d=224.0.0.10(FastEthernet0/0), > > len 77, sending broad/multicast, proto=88 > > Jul 15 11:39:54.727: IP: s=10.0.0.1 (local), d=224.0.0.10(FastEthernet0/0), > > len 69, sending broad/multicast, proto=88 > > Jul 15 11:39:54.731: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d= > 10.0.0.1 > > (FastEthernet0/0), routed via RIB > > Jul 15 11:39:54.731: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1 > > (FastEthernet0/0), len 69, rcvd 3, proto=88 > > Jul 15 11:39:54.735: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d= > 10.0.0.1 > > (FastEthernet0/0), routed via RIB > > Jul 15 11:39:54.735: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1 > > (FastEthernet0/0), len 40, rcvd 3, proto=88 > > Jul 15 11:39:54.739: IP: s=10.0.0.1 (local), d=10.0.0.2(FastEthernet0/0), > > len 69, sending, proto=88 > > Jul 15 11:39:54.747: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d= > 10.0.0.1 > > (FastEthernet0/0), routed via RIB > > Jul 15 11:39:54.747: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1 > > (FastEthernet0/0), len 69, rcvd 3, proto=88 > > Jul 15 11:39:54.751: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d= > 10.0.0.1 > > (FastEthernet0/0), routed via RIB > > Jul 15 11:39:54.755: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1 > > (FastEthernet0/0), len 40, rcvd 3, proto=88 > > Jul 15 11:39:54.755: IP: s=10.0.0.1 (local), d=10.0.0.2(FastEthernet0/0), > > len 40, sending, proto=88 > > Jul 15 11:39:54.963: IP: s=10.0.0.1 (local), d=10.0.0.2(FastEthernet0/0), > > len 69, sending, proto=88 > > Jul 15 11:39:54.971: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d= > 10.0.0.1 > > (FastEthernet0/0), routed via RIB > > Jul 15 11:39:54.971: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1 > > (FastEthernet0/0), len 40, rcvd 3, proto=88 > > Jul 15 11:39:55.139: %SYS-5-CONFIG_I: Configured from console by console > > R1# > > > > Once converged only periodic multicast hellos are exchanged until > something > > changes in the topology. > > > > Jul 15 11:39:59.551: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len > 60, > > rcvd 2, proto=88 > > Jul 15 11:39:59.579: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), > len > > 60, sending broad/multicast, proto=88 > > Jul 15 11:39:59.579: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, > rcvd > > 2, proto=88 > > Jul 15 11:39:59.687: IP: s=10.0.0.1 (local), d=224.0.0.10(FastEthernet0/0), > > len 60, sending broad/multicast, proto=88 > > Jul 15 11:40:04.202: IP: s=10.0.0.1 (local), d=224.0.0.10(FastEthernet0/0), > > len 60, sending broad/multicast, proto=88 > > Jul 15 11:40:04.495: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), > len > > 60, sending broad/multicast, proto=88 > > Jul 15 11:40:04.495: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, > rcvd > > 2, proto=88 > > Jul 15 11:40:04.539: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len > 60, > > rcvd 2, proto=88 > > Jul 15 11:40:08.838: IP: s=10.0.0.1 (local), d=224.0.0.10(FastEthernet0/0), > > len 60, sending broad/multicast, proto=88 > > Jul 15 11:40:09.190: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len > 60, > > rcvd 2, proto=88 > > Jul 15 11:40:09.270: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), > len > > 60, sending broad/multicast, proto=88 > > Jul 15 11:40:09.270: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, > rcvd > > 2, proto=88 > > > > > > > > > > HTH, > > > > Brian McGahan, CCIE #8593 (R&S/SP/Security) > > bmcgahan@internetworkexpert.com > > > > Internetwork Expert, Inc. > > http://www.InternetworkExpert.com > > Toll Free: 877-224-8987 x 705 > > Outside US: 775-826-4344 x 705 > > Online Community: http://www.IEOC.com > > CCIE Blog: http://blog.internetworkexpert.com > > > > > > > > Jonathan Greenwood II wrote: > > > > Peter well said you hit it right on the nail. > > > > On Tue, Jul 15, 2008 at 12:38 PM, Cisco Addicted > > > > wrote: > > > > > > > > Peter, > > Thank you very much for the sharp and bright clarification. Really you > > shot > > the head of this issue. > > > > Regards. > > Moe > > > > -----Original Message----- > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of > > Peter Stephan > > Sent: Tuesday, July 15, 2008 7:42 PM > > To: 'Nate Cielieska'; 'Igor Manassypov' > > Cc: 'Jonathan Greenwood II'; 'GS CCIE-Lab' > > Subject: RE: rip passive int with neighbor command > > > > Just to remember: > > > > In EIGRP: > > If you enable unicast updates on an interface, you DISABLE multicasting > > updates to 224.0.0.10 through that particular interface. > > > > In RIP v2: > > If you enable unicast updates on an interface (through neighbor cmd), you > > 'DO NOT STOP' multicasting updates. > > You use then passive-interface to stop multicasting updates if it was > > required. > > > > > > Don't confuse yourself... just remember in EIGRP you either have unicast > or > > multicast, in RIP you can have both (unless you use passive-int). > > > > Cheers, > > Peter. > > > > -----Original Message----- > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of > > Nate > > Cielieska > > Sent: Tuesday, July 15, 2008 8:24 PM > > To: Igor Manassypov > > Cc: Jonathan Greenwood II; GS CCIE-Lab > > Subject: Re: rip passive int with neighbor command > > > > Igor, > > > > When you turn on unicast updates with the "neighbor x.x.x.x" command, > this > > does not disable the multicast updates out of that interface. It merely > > sends that particular neighbor a unicast update and sends out a > > 224.0.0.9multicast update as well.. to stop the multicast updates you > used > > the passive-interface command. The passive-interface command has no > bearing > > on your unicast updates so your updates will be seen on your router.. > > meeting your requirements. > > > > Regards, > > Nate > > > > On Tue, Jul 15, 2008 at 10:58 AM, Igor Manassypov > > > > wrote: > > > > > > > > if I configure that interface on which my neighbor sits as passive, > > and I also configure a neighbor command explicitly, are routes going > > to be exchanged? > > > > Jonathan Greenwood II wrote: > > Igor when you use the > > neighbor command you are sending RIP updates via unicast by > > specifiying the IP Address of the neighboring router as opposed to the > > multicast address 224.0.0.9 which all rip enabled interfaces listen > > on. Passive interface with RIP doesn't allow updates to be sent out > > the interface but an interface can still receive updates from my > > > > > > understanding. > > > > > > To actually form the neighbor relationship the interface should not be > > configured for passive interface. You could also peform RIP > > authentication on both sides depending on the requirements/restrictions > > > > > > of > > the question. > > > > > > HTH > > > > Jonathan > > > > On Tue, Jul 15, 2008 at 9:44 AM, Igor Manassypov > > wrote: > > > > > > > > Could someone please clarify rip's neighbor command mixed with a > > passive-interface? For example, if you are asked to make sure that > > > > > > routing > > > > > > updates are only sent to a particular router, I will configure a > > corresponding 'neighbor' entry under my rip process, but to satisfy > > the requirement that only that particular router gets updates I > > would also > > > > > > need > > > > > > to enable the passive interface. As soon as I do that, there are no > > more routing updates coming from that interface even though I have > > an explicit neighbor configured... If I do not use the passive > > interface, then other routers will get updates breaking the > > > > > > requirement... > > > > > > > > ____________________________________________________________________ > > ___ Subscription information may be found at: > > http://www.groupstudy.com/list/CCIELab.html > > > > > > > > ______________________________________________________________________ > > _ Subscription information may be found at: > > http://www.groupstudy.com/list/CCIELab.html > > > > > > ______________________________________________________________________ > > _ Subscription information may be found at: > > http://www.groupstudy.com/list/CCIELab.html > > > > > > > > _______________________________________________________________________ > > Subscription information may be found at: > > http://www.groupstudy.com/list/CCIELab.html > > > > > > _______________________________________________________________________ > > Subscription information may be found at: > > http://www.groupstudy.com/list/CCIELab.html > > > > > > > > > > _______________________________________________________________________ > > Subscription information may be found at: > > http://www.groupstudy.com/list/CCIELab.html > > > > > > _______________________________________________________________________ > > Subscription information may be found at: > > http://www.groupstudy.com/list/CCIELab.html > > > > > > > > > > > > > > > > Igor M., M.Eng, P.Eng > > Network Architect > > > > > > _______________________________________________________________________ > > Subscription information may be found at: > > http://www.groupstudy.com/list/CCIELab.html > > > > > > > > > > > > > > -- > Victor Cappuccio > CCIE R/S# 20657 > CCSI# 30452 > www.vcappuccio.wordpress.com > > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:55 ART