From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Wed Jun 23 2004 - 00:03:05 GMT-3
Jim,
The only answer to the question is NAT. (I know because I wrote
the question ;)
The question reads as follows:
5.30. Enable IP routing on SW2.
5.31. SW2's only connection to the rest of the routing domain is through
R5.
In order to minimize memory and CPU utilization on SW2, the only
routes that it should have are those which are directly connected.
5.32. All other routers should still have IP reachability to SW2's
loopback
address.
5.33. You are allowed one static route on R5.
The key to understanding the answer to the question is to look
at the requirements and restrictions of the section, and eliminate
possible options step by step.
First the question states to enable IP routing on the switch.
This eliminates the switch from sending traffic out an interface unless
it has a route to the destination, either through a dynamic, static, or
directly connected route. This stipulation also eliminates configuring
IRDP on R5 (the directly connected neighbor) because the "ip
default-gateway" is only effective when IP routing is disabled.
The next stipulation states that SW2 should not have any other
routes installed in the routing table except the directly connected
ones. This eliminates running any type of dynamic routing protocol, or
configuring static routes on SW2. While this does eliminate the option
of R5 originating a default route to SW2 via ODR, simply because there
cannot be a default route installed, if you actually tried this solution
you would see that the 3550 does not listen for ODR advertisements. I
don't recall if this is missing from the feature navigator for the 3550
image, but if you simply try it you'll see that it doesn't work.
Now we know that the only information the routing table can give
us is information about directly connected networks. This means that if
SW2 wants to send traffic out, it must either be to a directly connected
network, or it must find the outgoing interface by some other means than
looking at the IP routing table. One of the ways that it can do this
without using the routing table is to use policy-based routing.
However, initial requirements in the lab scenario simply state that
policy routing cannot be used.
Now it is evident that SW2 cannot send traffic to a destination
unless it is directly connected. However, we still have the requirement
that "All other routers should still have IP reachability to SW2's
loopback
address." Note however that the requirement does not state that SW2
must have reachability to everyone else, just that everyone must have
reachability to SW2 (a fine distinction, but as we will see is the
determining factor in this question) Now let's step aside and think
about how the other devices will get to SW2, and worry about how SW2
will get back later.
SW2 is not running a dynamic routing protocol. This means that
the loopback network cannot be advertised on to R5 dynamically. Looking
at the next stipulation of the requirement it is seen that we "are
allowed one static route on R5." The ability to have this static route
configured on R5 gives us a simple fix for the problem. Instead of SW2
advertising the route dynamically and R5 passing it on, R5 will just
have a static route for the destination, and then dynamically pass the
static route on. This is simply accomplished by something like this:
ip route 150.1.8.0 255.255.255.0 ethernet0/0
!
router ospf 1
redistribute static subnets
Now R5 has a route to the destination, as does everyone in the
dynamic routing domain.
Now getting back to the problem on SW2, we see that everyone can
send traffic to SW2 (since now they have the route), but SW2 cannot
reply because the traffic is coming from sources that are not directly
connected. Therefore we need to deduce how to make the incoming traffic
look like it is actually coming from a directly connected network. And
the answer is... NAT.
By configuring NAT on R5 we can change the source IP address of
all traffic going towards SW2 to an address that SW2 knows how to get
back to. Since SW2 only knows how to get to directly connected
networks, that address must be directly connected. The configuration
would look something like:
interface ethernet0/0
ip nat outside
!
interface (all other interfaces)
ip nat inside
!
ip nat inside source list 1 interface ethernet0/0 overload
!
access-list 1 permit any
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> ccie2be
> Sent: Tuesday, June 22, 2004 4:10 PM
> To: Baety Wayne A 30 SIG BN RS3 (cn); swm@emanon.com; 'MMoniz'; 'Group
> Study'
> Subject: Re: Routing without routing protocol
>
> RE: Routing without routing protocolWayne,
>
> A form of PBR? I think that's a big stretch but... in any case.
>
> Here's how I understand it.
>
> Once a static route is allowed on R5, there's no problem getting to
the
> Cat's
> lo0 from R5. And, if you redist the static into the IGP running on R5
then
> all
> routers can also ping to the Cat lo0.
>
> So far, so good.
>
> Now, the problem is how to make the Cat send back a reply to pings
from R5
> or
> other routers in the network.
>
> Since the Cat is only allowed to have directly connected interfaces in
> it's
> route table, some way must exist to make the Cat think a ping is
coming
> from a
> directly connected interface, let's say R5's interface which connects
to
> the
> Cat.
>
> What if all pings arriving at the Cat had a source address of R5's
> interface?
> That would work since the CAT knows how to reply to a ping coming in
from
> a
> directly connected interface.
>
> To do this, just configure NAT with overload. Now all ping source ip
> addresses are translated to R5's interface facing the Cat as they
leave
> R5.
> When they return to R5, R5 just unNAT's them.
>
> The real challenge of this task was to realize to use NAT. Once that
> realization is made, the rest of it is pretty easy. Agree?
>
> Tim
>
>
>
>
>
> ----- Original Message -----
> From: Baety Wayne A 30 SIG BN RS3 (cn)
> To: 'swm@emanon.com' ; 'ccie2be' ; Baety Wayne A 30 SIG BN RS3 (cn)
;
> 'MMoniz' ; 'Group Study'
> Sent: Tuesday, June 22, 2004 4:56 PM
> Subject: RE: Routing without routing protocol
>
>
> Must have slipped my slippery mind, but yes NAT would definitely
solve
> one
> traffic direction, destined for the lo0 but is it not a form of PBR?
How
> do
> you handle traffic returning from the 3550 w/o using ip default
network or
> the
> other ideas previously mentioned?
>
> WAYNE A. BAETY, Contr, 30SIG BN
> MCSE+I, MCSD, MCDBA, CCNP+Voice
> Resident System Support Specialist
> Office: (808) 655-6761
> Cell: (808) 779-3776
>
>
>
> -----Original Message-----
> From: Scott Morris [mailto:swm@emanon.com]
> Sent: Tuesday, June 22, 2004 10:18 AM
> To: 'ccie2be'; 'Baety Wayne A 30 SIG BN RS3 (cn)'; 'MMoniz'; 'Group
> Study'
> Subject: RE: Routing without routing protocol
>
> That's a whole lot of things that you are not allowed to do there.
:)
>
> So since it said "unless specifically stated", what kinds of things
ARE
> you
> allowed to do? What is supposed to be running on this 3550.
Perhaps
> that
> would help narrow down the solution set.
>
> If you mentioned these in an earlier e-mail, sorry I missed 'em!
(over
> aggressive filtering?)
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
> CISSP,
> JNCIP, et al.
> IPExpert CCIE Program Manager
> IPExpert Sr. Technical Instructor
> swm@emanon.com/smorris@ipexpert.net
> http://www.ipexpert.net
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> ccie2be
> Sent: Tuesday, June 22, 2004 4:03 PM
> To: Baety Wayne A 30 SIG BN RS3 (cn); MMoniz; Group Study
> Subject: Re: Routing without routing protocol
>
> RE: Routing without routing protocolHi Wayne,
>
> Wow, you really thought alot about this. Very impressive.
>
> I really liked the irdp method since I was aware of it but not sure
how
> to
> really implement it - what gets enabled on what device.
>
> But, unfortunately, each method you discussed violated either the
> specific
> constraints of the task or the general lab rules such as don't use
> static,
> default, or PBR. Don't add or change ip address. Don't add routing
> protocols
> unless specifically stated.
>
> But, of all the ways you mentioned, why didn't you mention NAT?
> Wouldn't
> that meet the requirements in your opinion?
>
> Thanks
> ----- Original Message -----
> From: Baety Wayne A 30 SIG BN RS3 (cn)
> To: 'ccie2be' ; MMoniz ; Group Study
> Sent: Tuesday, June 22, 2004 3:47 PM
> Subject: RE: Routing without routing protocol
>
>
>
> The simplest solution is to enable OSPF on the 3550 and add the
lo0
> and
> 3550-R5 links to your OSPF routing process. But if you cannot
enable
> OSPF
> (by the lab specifically stating you may not enable OSPF on the
3550-R5
> link), the next simplest solution is to enable another shared
routing
> protocol on the
> 3550-R5 link and then selectively redistributing learned networks
into
> the
> OSPF process on R5. Many alternate routing protocols have a way of
> self-originating a default route on R5 to your 3550, including OSPF,
and
> then filtering all other routes. A routing protocol generated
default
> route
> doesn't violate the no "static default" rule. You may do the second
> solution as long as the lab doesn't have verbiage about not enabling
any
> routing-process on the 3550-R5 link.
>
> The third option is to rely on proxy arp on the 3550, which in
most
> cases
> leads to arp cache thrashing, is a performance hit and shouldn't be
used
> in
> a live network. By enabling proxy arp on R5 (on by default) and
using a
> shorter subnet mask on the 3550, the 3550 will use arp to obtain
> reach-ability to the rest of the network. You can also use
secondary
> networks on the 3550 to make it believe other networks are local to
its
> R5-3550 link, in which case R5 will respond with an arp reply for
each
> instance. Then use PBR on R5 to reach the loopback of the 3550.
>
> The fourth option is to disable routing on the 3550 and use ip
> default-network pointing to R5. This takes care of one direction,
3550
> to
> the rest of the world. Then use PBR on R5, creating a route-map
> pointing to
> destinations of lo0 to the 3550. This takes care of reach-ability
to
> the
> 3550's lo0, both traffic directions satisfied. If the lab
specifically
> states you can not use a _default network_ (note: this is not a
static
> default route which is of the form ip route 0.0.0.0 x.x.x.x....) or
> specifically states you can not disable routing on the 3550, then
there
> are
> other ways of getting the 3550 to view R5 in "default" ways. IRDP
is
> one,
> which requires you to disable routing on the 3550 and enabling IRDP
> style
> Gateway Discovery Protocol. DHCP is another (requires the EasyIP
feature
> set). IRDP relies on the fact that you configure R5 (by enabling ip
> irdp)
> to broadcast or multicast hello messages on the 3550-R5 link.
What's
> neat
> about IRDP is that you can configure static routes with it w/o
violating
> many labs static route rule w/ its proxy-advertise feature. If you
> enable
> ip gdp irdp on the 3550 and ip irdp on R5 you can take care of both
> traffic
> directions.
>
> Keep in mind these labs are designed to test how fluid you are
with
> configuring a Cisco router. So, learn all the ways you can
configure
> reach-ability and you should be all set. (Ever heard of ODR?)
>
> Regards,
>
> WAYNE A. BAETY, Contr, 30SIG BN
> MCSE+I, MCSD, MCDBA, CCNP+Voice
> Resident System Support Specialist
> Office: (808) 655-6761
> Cell: (808) 779-3776
>
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> Of
> ccie2be
> Sent: Tuesday, June 22, 2004 5:17 AM
> To: MMoniz; Group Study
> Subject: Re: Routing without routing protocol
>
> Hey Mike,
>
> Option isn't allowed - the instructions explicitly told me to
enable
> ip
> routing on the 3550.
>
> Re: irdp. I thought of that this morning but I thought if irdp
were
> used,
> it
> would have to be on the 3550. However, since there's no routing
> protocol
> running on the link between the 3550 and R5, there wouldn't be any
> routing
> updates to listen for.
>
> Also, if I remember correctly, irdp only listens for rip or igrp
> updates
> and
> only ospf is running on R5.
>
> I think there's still something else I'm missing.
>
> Thanks, I'm sure I'll find out, Tim
>
> ----- Original Message -----
> From: "MMoniz" <ccie2002@tampabay.rr.com>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study"
> <ccielab@groupstudy.com>
> Sent: Tuesday, June 22, 2004 10:28 AM
> Subject: RE: Routing without routing protocol
>
>
>
>
> > Well I would say you have basically 2 options here.
> >
> > 1. Use IRDP on R5
> >
> > 2. Disable IP routing on the Cat and configure a
default-gateway.
> This
> is
> > not a static route or a static network!!
> >
> > Mike
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
Behalf
> Of
> > ccie2be
> > Sent: Tuesday, June 22, 2004 10:10 AM
> > To: Group Study
> > Subject: Routing without routing protocol
> >
> >
> > Hi All,
> >
> > This one got me.
> >
> > 3550 has routing enabled but no routing protocols enabled.
> >
> > It's only path to the rest of the network is via R5. All other
> routers
> on
> > the
> > other side of R5 must be able to ping the 3550's loopback.
> >
> > I'm allowed to use one static route on R5.
> >
> > This is what it looks like:
> >
> > 3550 lo0 fa0/5 ------- e0/1 R5 ----- rest of network
> >
> > How do I provide reachabiltiy to the 3550's lo0 without
violating
> lab
> rules
> > ie
> > no default routes or default networks and
> > no static routes except the one explicitly allowed here?
> >
> > Please tell me what I'm missing. Thanks, Tim
> >
> >
>
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:48 GMT-3