From: Gustavo Novais (gustavo.novais@novabase.pt)
Date: Thu Dec 15 2005 - 17:18:26 GMT-3
That would also be nice solution, thinking out of the box and
configuring the switch that interconnects the segment.
But a Vlan-map would filter traffic on all the vlan. So we would be able
to specify that BB3 does not input packets to 224.0.0.10, but we
wouldn't be able to say that BB3 does not receive the multicast traffic.
IP access-lists on the layer 2 port of the BB3 would only filter IP
traffic incoming from BB3, not going to BB3. If the port was a L3, then
we would be able to filter inbound and outbound.
Thanks
Gustavo Novais
-----Original Message-----
From: Wang Dehong-DWANG1 [mailto:Dehong.Wang@motorola.com]
Sent: quinta-feira, 15 de Dezembro de 2005 20:09
To: Gustavo Novais; Vincent Mashburn; Cisco certification
Subject: RE: IEWB3.0 lab 14 4.5 -- EIGRP router not intercept eigrp
updates
Wonder whether you can match mac-address(224.0.0.10) with class-map, and
use policy-map on the interface to BB3..
Or vlan-map?
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gustavo Novais
Sent: Thursday, December 15, 2005 1:45 PM
To: Gustavo Novais; Vincent Mashburn; Cisco certification
Subject: RE: IEWB3.0 lab 14 4.5 -- EIGRP router not intercept eigrp
updates
Hi,
At the moment the solution I've reached is to configure a tunnel
"triangle" using ip unnumbered fa0/0 on the three routers that speak
eigrp, and passive interface on the fast interfaces of R1,R3,R6. This
way the adj are established through the tunnels and not flooded through
the Ethernet segments, thus not reaching BB3.
This was the best I could think of. Any feedback is appreciated.
(Brians?)
Gustavo Novais
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gustavo Novais
Sent: quinta-feira, 15 de Dezembro de 2005 19:22
To: Vincent Mashburn; Cisco certification
Subject: RE: IEWB3.0 lab 14 4.5 -- EIGRP router not intercept eigrp
updates
As you may easily understand why, configuring BB3 is not an option.
Thank you for your input.
Gustavo Novais
-----Original Message-----
From: Vincent Mashburn [mailto:vmashburn@fedex.com]
Sent: quinta-feira, 15 de Dezembro de 2005 19:19
To: Gustavo Novais; Cisco certification
Subject: RE: IEWB3.0 lab 14 4.5 -- EIGRP router not intercept eigrp
updates
Configure an access-list on BB3 to deny EIGRP from the devices on the
Ethernet segement.
Vince Mashburn
Engineer
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gustavo Novais
Sent: Thursday, December 15, 2005 12:50 PM
To: Cisco certification
Subject: IEWB3.0 lab 14 4.5 -- EIGRP router not intercept eigrp updates
Hello.
We have an Ethernet segment with R1, R3, R6 and BB3 on it.
R1,R3, R6 are speaking eigrp 10.
Task says : Do not allow BB3 to intercept EIGRP updates coming from any
of the eigrp speaking routers.
Do not use the neighbour command.
I can think of several ways of fulfilling the requirements, but all fail
in some small way, namely, because of the meaning of the word INTERCEPT.
Intercept can be thought as simply being able to listen to the packets,
at least I'm assuming so. If it is only not being able to establish
adjacency, then the task is trivial.
Authentication on R1,R3, R6 - If updates are authenticated, they are
still multicast - BB3 can still intercept the encrypted packets,
although is not (theoretically) capable to crack the key. This can be a
probable solution.
R1, R3, R6 have different k values from the default ones - It would
simply be a trial and error situation of trying to get the right values,
because the router complains always of mismatch k values. Although
avoiding adjacencies, the multicast packets are always there.
We can try to NAT multicast EIGRP packets into a unicast address, as
posted on a thread some time ago, but for RIP.
This seems to fulfil the requirement, since BB3 does not listen to them.
The problem is that each router has TWO neighbors. If I change EIGRP
multicast to unicast through NAT (I do not know if possible, but... ) I
will have to find a way to duplicate packets. Unless I NAT 224.0.0.10 to
something else also multicast.
Does anybody have any thoughts on task interpretation? Perhaps the
Brians, who wrote it?
I think I may be overcomplicating it...
TIA
Gustavo Novais
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:51 GMT-3