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]<mailto:[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<http://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]>
[mailto:[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<http://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. 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
