2

Current connection path: 10.40.20.0/24 desktop <-> access switch <-> core switch <-> 10.30.15.33 NAT firewall for internet access

Objective: adding additional path as following to test another new NAT firewall which have IP 10.40.15.33; While all other desktop on 10.40.20.0/24 except 10.40.20.8 desktop would go to 10.30.15.33 as usual.

New additional connection path: 10.40.20.8 desktop <-> access switch <-> core switch

Original routing config on access switch (No dynamic routing protocol):

interface Vlan420
 description OFFICE USER LAN
 ip address 10.40.20.254 255.255.255.0

ip route 0.0.0.0 0.0.0.0 10.40.15.78

Original config on core switch (Contain dynamic routing protocol):

interface Vlan451
 description INTER SWITCH INTERNAL LAN
 ip address 10.40.15.78 255.255.255.240

ip route 0.0.0.0 0.0.0.0 10.30.15.33

route-map static2ospf permit 10 
 match tag 100
 set metric-type type-1

router ospf 10
 router-id 10.40.15.254
 redistribute connected route-map connected2ospf
 redistribute static route-map static2ospf
 passive-interface default
 no passive-interface GigabitEthernet1/0/46
 no passive-interface GigabitEthernet1/0/47
 no passive-interface TenGigabitEthernet1/1/4
 no passive-interface GigabitEthernet2/0/47
 no passive-interface TenGigabitEthernet2/1/4
 network 10.0.1.0 0.0.0.15 area 0
 network 10.0.1.16 0.0.0.15 area 0
 network 10.0.6.0 0.0.0.15 area 0
 network 10.0.6.16 0.0.0.15 area 0
 network 10.0.7.0 0.0.0.15 area 0

working traceroute from 10.40.20.8 (Ping loss expected after 10.0.6.2 because we have a firewall to block traceroute and ping)

traceroute -n  10.30.15.33
traceroute to 10.30.15.33 (10.30.15.33), 30 hops max, 60 byte packets
 1  10.40.20.254  1.775 ms  2.074 ms  1.968 ms
 2  10.40.15.78  1.422 ms  1.318 ms  1.620 ms
 3  10.0.6.2  2.121 ms  2.439 ms  2.734 ms
 4  * * *
 5  * * *



After applying this line of config on core switch, 10.40.20.8 route to everywhere start failing

ip route 10.40.20.8 255.255.255.255 10.30.15.33 tag 100 name my_test

failing traceroute from 10.40.20.8 (all packet stuck at 10.40.20.254 which is the access switch VLAN420 interface

traceroute -n  10.30.15.33
traceroute to 10.30.15.33 (10.30.15.33), 30 hops max, 60 byte packets
 1  10.40.20.254  1.791 ms  1.650 ms  1.537 ms
 2  * * *
 3  * * *

Question: access switch pointing default gateway to 10.40.15.78 which is the core switch, then in core switch it's going default gateway to 10.30.15.33; What's wrong on the routing after I put a more specific route via "ip route" command with same default gateway?

Remark: We are trying to put in static route for old internet firewall 10.30.15.33 before putting 10.40.15.33

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. – Ron Maupin Dec 16 '20 at 23:27
-1

If I understand you correctly, the host 10.40.20.8 is still connected to ACCESS switch Vlan420.

Why did you add a route 10.40.20.8/32 -> 10.30.15.33 on CORE switch? That prevents the CORE switch, and everything upstream, from correctly routing packets to the 10.40.20.8 host. That's why the traceroute doesn't progress further than the ACCESS switch.

What's wrong on the routing after I put a more specific route via "ip route" command with same default gateway?

When the CORE switch gets traceroute packets from 10.40.20.8 it attempts to reply but the replies go the wrong way -- up to 10.30.15.33 instead of down to the ACCESS switch which would forward them to the host. The static route you added broke the routing for 10.40.20.8 by misdirecting traffic bound for that IP.

So the question is, what are you trying to accomplish by configuring the mentioned static route?

ACCESS# ip route 10.40.20.8 255.255.255.255 10.30.15.33 tag 100 name my_test
  • The static route is an experiment to confirm static route is working, which we will use another IP replacing 10.30.15.33 to another IP, also, can you please edit answer? You didn't include answer but rather a question / statement – Thomas G. Lau Aug 25 '20 at 23:07
  • I'm not sure what kind of answer you're looking for, other than the above. Either you or I have a significant misunderstanding about your topology & question. The reason your traceroute test stopped working when you configured the static route is you "broke" the route to 10.40.20.8 by configuring the static route. Your new static route directs traffic away from the actual host, not toward it. If you could explain your goal more clearly, it might be possible to provide a better answer. – Jeff Wheeler Aug 25 '20 at 23:57
  • adding some more details on the original post, please check – Thomas G. Lau Aug 26 '20 at 0:19
  • my question is how to make static route work for 10.40.20.8 desktop, which I could point to anywhere. – Thomas G. Lau Aug 26 '20 at 0:20
  • If I understand correctly, upstream of your CORE switch, you have a firewall/NAT device (existing) and want to test a new one (new.) That's not as simple as putting in a static route; in fact it requires a lot of effort in your topology. The reason is you need incoming traffic to your network for the test workstation to pass through the NEW NAT device, and outgoing traffic -- only from that workstation -- to pass out via the NEW device. You have a really big misunderstanding of how this stuff works together. – Jeff Wheeler Aug 26 '20 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.