Steve, Thank you very much once again for nice explaination....and also for quick response...
Thanks Nilesh On Thu, Oct 21, 2010 at 11:24 AM, Di Bias, Steve <[email protected]>wrote: > Nilesh, > > > > While it may look like you are forming a neighbor relationship from the > perspective of the router in question, I don’t think you actually are. For > example (using my 3rd router scenario) I just brought FA0/0 up on R4 and > at first it looks like I’m forming neighborships with R1 and R2 > > > > *Mar 4 02:21:15.821: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor > 150.100.12.2 (FastEthernet0/0) is up: new adjacency > > *Mar 4 02:21:19.177: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor > 150.100.12.1 (FastEthernet0/0) is up: new adjacency > > > > However give this a little time and you will see the following > > > > *Mar 4 02:22:35.333: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor > 150.100.12.2 (FastEthernet0/0) is down: retry limit exceeded > > *Mar 4 02:22:38.689: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor > 150.100.12.1 (FastEthernet0/0) is down: retry limit exceeded > > > > But even when the peer seems to come back (according to R4) we have some > other issues… > > > > *Mar 4 02:24:01.269: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor > 150.100.12.1 (FastEthernet0/0) is up: new adjacency > > *Mar 4 02:24:01.545: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor > 150.100.12.2 (FastEthernet0/0) is up: new adjacency > > > > At this point I verified R4’s EIGRP neighbor table (notice the neighbors > are there with SEQ of 0) > > > > R4(config-if)#do sh ip ei ne > > IP-EIGRP neighbors for process 1 > > H Address Interface Hold Uptime SRTT RTO Q > Seq > > (sec) (ms) Cnt > Num > > *1 150.100.12.1 Fa0/0 13 00:00:33 1 5000 1 > 0 **ß** R4 says R1 is our neighbor*** > > *0 150.100.12.2 Fa0/0 12 00:00:39 1 5000 1 > 0 **ß** R4 says R2 is our neighbor* > > > > What do we see on R1 and R2? > > > > R1(config-if)#do sh ip ei ne > > IP-EIGRP neighbors for process 1 > > H Address Interface Hold Uptime SRTT RTO Q > Seq > > (sec) (ms) Cnt > Num > > *0 150.100.12.2 Fa0/0 12 00:29:20 2 200 0 > 53 **ß** R1 doesn’t see R4 as a neighbor*** > > > > R2#sh ip ei ne > > IP-EIGRP neighbors for process 1 > > H Address Interface Hold Uptime SRTT RTO Q > Seq > > (sec) (ms) Cnt > Num > > 0 150.100.12.1 Fa0/0 13 00:29:06 332 1992 0 54 > *ß** R2 doesn’t see R4 as a neighbor*** > > > > If we run a debug on R1 and R2 for EIGRP packets we will see the following > over and over again > > > > *May 18 03:35:21.237: EIGRP: Sending HELLO on FastEthernet0/0 > > *May 18 03:35:21.237: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 > > *May 18 03:35:21.245: EIGRP: Received UPDATE on FastEthernet0/0 nbr > 150.100.12.4 > > *May 18 03:35:21.245: AS 1, Flags 0x9, Seq 75/0 idbQ 0/0 > > *May 18 03:35:21.245: EIGRP: Neighbor(150.100.12.4) not yet found > > *May 18 03:35:22.245: EIGRP: Received HELLO on FastEthernet0/0 nbr > 150.100.12.1 > > *May 18 03:35:22.245: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 > peerQ un/rely 0/0 > > *May 18 03:35:23.245: EIGRP: Received UPDATE on FastEthernet0/0 nbr > 150.100.12.4 > > *May 18 03:35:23.245: AS 1, Flags 0x9, Seq 75/0 idbQ 0/0 > > *May 18 03:35:23.245: EIGRP: Neighbor(150.100.12.4) not yet found > > > > What you are seeing here is that when R1 and R2 send their HELLO packets to > 224.0.0.10 R4 sees it and tries to respond, however since R4 can’t send to > 224.0.0.10 it never makes it over to R1 and R2 and hence only R4 see’s R1 > and R2 as neighbors, and not vice versa. Since R4 can’t seem to say HELLO > they don’t show ip in the neighbor table. > > > > So as you can see the VACL is blocking the neighbor relationship form > forming because the only two nodes that can send multicast packets to > 224.0.0.10 are 150.100.12.1 and 150.100.12.2. Sometimes the VACL’s can be a > little confusing because when they use reverse logic (e.g. permit to deny), > but If you look at ACL 101 and the VACL NOEGIRP you will see what I mean. > > > > access-list 101 deny eigrp host 150.100.12.1 host 224.0.0.10 (this deny > will be permitted through the VACL) > > access-list 101 deny eigrp host 150.100.12.2 host 224.0.0.10 (this deny > will be permitted through the VACL) > > access-list 101 permit eigrp any host 224.0.0.10 (this permit will be > denied in the VACL) > > > > vlan access-map NOEIGRP 10 > > match ip address 101 (matches ACL 101 and denies the first two statements > from being filtered) > > action drop (Drops all of the traffic in the last statement (any to > 224.0.0.10) > > vlan access-map NOEIGRP 20 > > action forward (Forwards everything else) > > ! > > vlan filter NOEIGRP vlan-list 12 (ties it to the vlan) > > > > Sorry for babbling! > > > > HTH > > > > Steve Di Bias > > > > *From:* Nilesh Mehta [mailto:[email protected]] > *Sent:* Thursday, October 21, 2010 10:11 AM > *To:* Di Bias, Steve > *Cc:* Winston Lee; CCIE > *Subject:* Re: [OSL | CCIE_RS] Vol 1 Lab 9 Task 9.19 > > > > Other simple way to test this-- > > > > instead of creating vlan 12 interface on R4 just shut down the fa0/0 on R1 > and change the ip address to 150.100.12.4 and bring it back. you neighbor > relation ship will be formed with R2 with your access-list as you have only > denied 150.100.12.1 in you access-list. That is why DSG solution is corrrect > to add the neighbot command . other wise other router will be able to form > neighbor relation ship. > > On Wed, Oct 20, 2010 at 8:52 PM, Di Bias, Steve <[email protected]> > wrote: > > Hey Winston, > > > > You were thinking outside the box on this one however I think you would > have lost points. > > > > The task specifically states that we need to “Secure VLAN 12 so that any > router added in the future will not be able to “see” EIGRP multicast packets > “or” form neighbor relationships with existing routers” > > > > The key words here are “see” and “or” and your configs only satisfy half of > this requirement. I just labbed this one up using your configuration and > then added R4’s interface to VLAN 12 (150.100.12.4/24) Since you are still > allowing 150.100.12.1 and 150.100.12.2 to send multicasts to 224.0.0.10 new > routers coming online will be able to see these. > > > > So bringing R4 online and running “debug ip packet” clearly shows that R1 > and R2 are sending multicast packets to 224.0.0.10 > > > > *Mar 3 12:17:20.089: IP: s=150.100.12.1 (FastEthernet0/0), d=224.0.0.10, > len 60, rcvd 2 > > *Mar 3 12:17:21.261: IP: s=150.100.12.2 (FastEthernet0/0), d=224.0.0.10, > len 60, rcvd 2 > > *Mar 3 12:17:25.069: IP: s=150.100.12.1 (FastEthernet0/0), d=224.0.0.10, > len 60, rcvd 2 > > *Mar 3 12:17:26.029: IP: s=150.100.12.2 (FastEthernet0/0), d=224.0.0.10, > len 60, rcvd 2 > > > > So while you may be able to stop neighbors from properly forming with your > configs, anyone on VLAN 12 will still be able to see the multicast traffic > destined to 224.0.0.10 > > > > HTH > > > > Steve Di Bias > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Winston Lee > *Sent:* Wednesday, October 20, 2010 7:05 PM > *To:* CCIE > *Subject:* [OSL | CCIE_RS] Vol 1 Lab 9 Task 9.19 > > > > Hello All, > > 9.19 Secure VLAN 12 so that any router added in the future will not be able > to see EIGRP multicast packets or form neighbor relationships with existing > routers. > > The DSG proposes putting a VACL and use the neighbor command between R1 and > R2 to accomplish this. I used a different method through a VACL alone and > was wondering if the way I did it was valid (would I have got points for > this on the lab)? > > > Cat3550-1#sh ip access-lists 101 > Extended IP access list 101 > 10 deny eigrp host 150.100.12.1 host 224.0.0.10 (68 matches) > 20 deny eigrp host 150.100.12.2 host 224.0.0.10 (31 matches) > 30 permit eigrp any host 224.0.0.10 > > Cat3550-1#sh vlan access-map NOEIGRP > Vlan access-map "NOEIGRP" 10 > Match clauses: > ip address: 101 > Action: > drop > Vlan access-map "NOEIGRP" 20 > Match clauses: > Action: > forward > > Cat3550-1#sh run | i filter > vlan filter NOEIGRP vlan-list 12 > > > > > > > UHS Confidentiality Notice: This e-mail message, including any attachments, > is for the sole use of the intended recipient(s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution of this information is prohibited, and may be > punishable by law. If this was sent to you in error, please notify the > sender by reply e-mail and destroy all copies of the original message. > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > > > > > UHS Confidentiality Notice: This e-mail message, including any attachments, > is for the sole use of the intended recipient(s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution of this information is prohibited, and may be > punishable by law. If this was sent to you in error, please notify the > sender by reply e-mail and destroy all copies of the original message. >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
