Play a game, solve the problem

[spidey07]

Just for fun, here's a puzzle to figure out.

SVR----L3 switchA----FW----L3 switch B----L3 switch C----L2 switchD---client.

SVR address is 200.200.200.200/24
L3 switch has interfaces into numerous 10.10.X.X/24 networks.
L3 switch B and C has numerous interfaces in 10.20.x.x/24 networks.
client IP is 10.20.20.20, L3 switch C is the default gateway for this network.

SVR trace to client stops a L3 switch C
L3 switchA trace to client GOOD
L3 switchB trace to client GOOD
SVR trace to any switch interface GOOD
Routing protocol is EIGRP, the firewall separates the two ASs. Default route of the firewall interfaces is respectively injected into each AS.
Any device can ping/trace to client except for nodes or interfaces in the 200.200.200.0/24 net.

What could the problem be? And more importantly, why. The firewall is not performing NAT/PAT of any kind and can be considered a L3 device.

You have been given all the information you need to know.

good luck, and have fun.

 

[spidey07]

Jeez, this is a game. Take a stab. Any stab. Roll the dice.

 

[phatrabt]

OK, so from your scenario it seems like L3 Switch C doesn't have a route back to the 200.200.200.0 subnet, possibly due to a missing network statement? It's one place I would look.

 

[spidey07]

Originally posted by: phatrabt
OK, so from your scenario it seems like L3 Switch C doesn't have a route back to the 200.200.200.0 subnet, possibly due to a missing network statement? It's one place I would look.

Nice shot! Thinking return path.

Switch C does NOT have a specific route in it's tables to 200.200.200.0.

Switch/router B and C are in the same AS and share the same routing database. 200.200.200.0 is caught by the static default route on SwitchB. *This is an important note, no route to 200.200.200.0/24.*, default route takes care of iy.

This AS is fully aware of and and has this default route. There are two ASs, the one on the left of the firewall and the one on the right.

"Routing protocol is EIGRP, the firewall separates the two ASs. Default route of the firewall interfaces is respectively injected into each AS. "

Very nice shot. You're close, but still off.

AS1 = left of firewall (contains 10.10.x.x, 200.200.200.0/24)
AS2 = right of firewall (contains 10.20.x.x, and a default)

 

[spidey07]

Originally posted by: phatrabt
OK, so from your scenario it seems like L3 Switch C doesn't have a route back to the 200.200.200.0 subnet, possibly due to a missing network statement? It's one place I would look.

Just to make it clear, SwitchB/C (and this entire AS, bounded by the firewall) only has a route OUT of it's AS of "go to the firewall".

The OP contains all you need.

 

[jersiq]

At first I though bad MPLS tagging, but MPLS can't be used in EIGRP.

So I guess that the metrics on Switch A have been changed from the metrics on the other switches in the topology.
I am going to make an assumption that by the trace "stopping" at switch C, it actually replies, but we never get to switch D.

That would mean that the ICMP never comes back from D because of the incorrect metric.

Mis-matched metrics can cause routing loops, which seems to be the case here, unless I am reading the problem wrong. I'd like to do the math/make an example but it's late, and I have to do my timesheet so I can leave work.

Bah, just realized that the trace to B is good, so there is no loop between the 10.x.x.x and 200.x.x.x network.

 

[kamper]

This is over my head, but I'll try a guess. Is switch A missing a route to 10.20.20.x? You haven't said anything about AS1 having a default route to 10.20.x.x. That doesn't fit with your encouragement to think return path though.

Edit: guessing this is wrong because "L3 switchA trace to client GOOD"

 

[spidey07]

Well, another hint. All routing is good, hence why all the L3 switches have full reachability. AS2 does not have a specific route to 200.200.200.0/24, this is picked up by the default route in the AS with a next hop of the firewall interface.

the only connectivity that doesn't work is from AS1, sourced with 200.200.200.200.0/24 interface to the client.

 

[m1ldslide1]

Originally posted by: spidey07
Just for fun, here's a puzzle to figure out.

SVR----L3 switchA----FW----L3 switch B----L3 switch C----L2 switchD---client.

SVR address is 200.200.200.200/24
L3 switch has interfaces into numerous 10.10.X.X/24 networks.
L3 switch B and C has numerous interfaces in 10.20.x.x/24 networks.
client IP is 10.20.20.20, L3 switch C is the default gateway for this network.

SVR trace to client stops a L3 switch C
L3 switchA trace to client GOOD
L3 switchB trace to client GOOD
SVR trace to any switch interface GOOD
Routing protocol is EIGRP, the firewall separates the two ASs. Default route of the firewall interfaces is respectively injected into each AS.
Any device can ping/trace to client except for nodes or interfaces in the 200.200.200.0/24 net.

What could the problem be? And more importantly, why. The firewall is not performing NAT/PAT of any kind and can be considered a L3 device.

You have been given all the information you need to know.

good luck, and have fun.

I have a few questions I think before I can answer this. You're saying that the firewall is running two separate instances of EIGRP, correct? AS1 and AS2 or something like that. I presume that the FW isn't advertising routes from one AS into the other. I start thinking about the default route and wondering where it is originating from. It must be configured on L3 switchA, pointing towards the firewall interface; and then also on L3 switch B, which would have to be redistributed into the AS. (L3 switchA being the only L3 device on that side of the firewall, no redist necessary). My guess is going to be based on this assumption.

The default route is configured on L3 switch B, switch B isn't configured to redistribute the default route into the EIGRP instance. Therefore L3 switch C has no default route, causing the trace from SVR to client to fail during the return path on switch C.

 

[spidey07]

Firewall is not running any kind of routing protocol. The default route is by a static on layer3 switch A and B with a next hope of the firewall interface that is into it's own AS, this default is then redistributed into EIGRP and each respective AS. Each AS has full reachability into the other from any device, except from 200.200.200.0/24 networks to/from the client.

Any host or interface in 200.200.200.0/24 has full reachability into all devices in AS1 and AS2. Only this single device has a problem.

Gotta go. Back to class. I think it's going to be full.

 

[InlineFive]

Originally posted by: spidey07
Firewall is not running any kind of routing protocol. The default route is by a static on layer3 switch A and B with a next hope of the firewall interface that is into it's own AS, this default is then redistributed into EIGRP and each respective AS. Each AS has full reachability into the other from any device, except from 200.200.200.0/24 networks to/from the client.

Any host or interface in 200.200.200.0/24 has full reachability into all devices in AS1 and AS2. Only this single device has a problem.

Gotta go. Back to class. I think it's going to be full.

Teaching or learning?

 

[spidey07]

Dude, that was a hint.

 

[m1ldslide1]

Originally posted by: spidey07
Dude, that was a hint.

If the answer is that your 10.X.X.X /24 networks are being hosed because of VLSM (or lack of), then that's kind of hard to discern without a config. It could be that EIGRP is configured without the "no auto-summary" command, which converts 10.20.X.X /24 into 10.0.0.0 /8 by default. It could be that a mask is misconfigured at one point or another. Show me a routing table from a couple of those routers and I think it'll be pretty apparent.

 

[spidey07]

All routing is correct with the correct masks. you're close though because of the behavior of EIGRP, no auto-summary is configured. It is a return problem from the client, everything is reachable except from the 200.200.200.0/24 network to this client. AS2 does NOT have a specific route to 200.2002.200.0 (this is the key).

I almost want to spit out the answer because I couldn't understand it until a big light bulb went off.

switch B table

Gateway of last resort is 10.20.254.254 to network 0.0.0.0

C 127.0.0.0/8 is directly connected, EOBC0/0
10.0.0.0/8 is variably subnetted, 66 subnets, 3 masks
-----output omitted, only contains 10.20.x.x networks with VLSM-----
S* 0.0.0.0/0 [1/0] via 10.20.254.254

 

[m1ldslide1]

Originally posted by: spidey07
All routing is correct with the correct masks. you're close though because of the behavior of EIGRP, no auto-summary is configured. It is a return problem from the client, everything is reachable except from the 200.200.200.0/24 network to this client. AS2 does NOT have a specific route to 200.2002.200.0 (this is the key).

I almost want to spit out the answer because I couldn't understand it until a big light bulb went off.

switch B table

Gateway of last resort is 10.20.254.254 to network 0.0.0.0

C 127.0.0.0/8 is directly connected, EOBC0/0
10.0.0.0/8 is variably subnetted, 66 subnets, 3 masks
-----output omitted, only contains 10.20.x.x networks with VLSM-----
S* 0.0.0.0/0 [1/0] via 10.20.254.254

I guess I'm stumped then, and it's bugging me because I'm starting to remember having seen this once before. I believe I had a lab set up to test default routing between EIGRP and OSPF in separate networks, but they had overlapping address space with VLSM. I think it was actually 10.X.X.X /8 in one network, and then 10.X.X.X /24 in the other (second octet never overlapped). That scenario sounds pretty similar to what you're describing.

L3 3750 (OSPF) <---> 1841 (both) <---> L3 3750 (EIGRP)

It's tough to remember exactly where it was hosing up without having access to the devices. But it's a tough one because you figure "well I have my default routes, they're redistributing, my addressing isn't *really* overlapping, etc" but you're still not getting full IP connectivity.

I'll wait patiently for the description/solution. :beer:

 

[spidey07]

Everybody is real close with the correct line of thinking - check routing, prefix lengths, return paths.

The key was the client and server did not have connectivity, the client is on a 10.20.x.x address, the server on a 200.200.200.x. The server could ping/trace anywhere except to the client. Somehow the client could not reach 200.200.200.0 hosts, but it could reach anything with a 10.10. or a 10.20. address.

My hint was CLASSFUL. Notice 10. is a class A address and 200.200.200.0 is a Class C. AS2 did not have a specific route to anything in AS1 (including 200.200.200.0) and relied on the default.

This hinted at a proxy-arp problem. Since AS2 did not have a specific route to 200.200.200.0 any router interface within this AS with proxy-arp enabled (default) would NOT answer an arp request for 200.200.200.200. It WOULD answer an arp request for any 10.0.0.0/8 address.

All this leads to the client relying on proxy-arp for reaching other subnets. Which means there is no default gateway configured on the client.

Proxy-arp strikes again in it's ability to mask what is really going on.

 

[Ninjazx]

ill take your word for it.

 

[Maldian]

Filters on the inbound interface, preventing the FW from routing the packet first, then having to possibly reject it later because of an access list condition?

 

[m1ldslide1]

Originally posted by: spidey07
Proxy-arp strikes again in it's ability to mask what is really going on.

I haven't yet run into proxy-arp problems, but I got to hear all about them at networkers best-practices classes this summer. Interesting example- thanks for sharing.

 

[Maldian]

The definition below indicates that switches A,B, and C have VLANs configured, but only in the 10.10/16 (subnetted into 24s) and 10.20/16 (also subnetting into 24s) ranges. The real interesting thing here is the mixing of the classful definitions (10 being class A, 200 being class C) so the possibility of class-based protocols acting in a default manner is real strong.

There was no mention of the 802.1q (trunking) capabilities of Switch D, but it is assumed that the L3 switches (A,B, and C) are all 802.1q standard. No mention is made of what type of firewall (ACL, SPI) is being used.



The fact that the server can ping ALL the switches (both sides of the firewall) implies the inter-vlan routing is OK and that the EIGRP is flowing on both sides. But the server can?t talk to the client, or is it really that the client can?t talk to the server? Hmmm, some routing tables would be REAL nice at this point. Again, I think you have a problem with routing through the networks because of a classful (read: old-school, hardcore, no stinking VLSM crap) translation back through the network.

 

[spidey07]

Routing tables aren't necessary in this case if you read the OP. But if you re-read you can pick out where the problem lies...the client can't reach 200.200.200 addresses.