topic Re: CE: layer2 redirect and GRE in Application Networking

CE: layer2 redirect and GRE

dschleyer — Fri, 18 Nov 2005 10:40:37 GMT

Hello,

customer wants to use WCCP and GRE for redirecting.

customer topologie:

Router 1 ---- Router 2 ----> G-WiN

| | |

| | | GRE fuer

Client 1

| | | L2redirect

for Client 2

| | |

Client 1 | +--- CE

Client 2

CE is configured as transparent.

Client 1 can use ce if GRE is configured. but client 2 get no connection to the internet.

any idea which is problem with that design ?

Thank you for any help

regards

Dietrich Schleyer

Re: CE: layer2 redirect and GRE

Zach Seils — Fri, 18 Nov 2005 14:07:24 GMT

hi Dietrich,

I don't understand the topology from the description you provided. Is there any way you could attach a diagram to the post?

thanks,

Zach

Re: CE: layer2 redirect and GRE

dschleyer — Tue, 22 Nov 2005 16:40:14 GMT

Hello Zach, thank you for your answer. enclosed you find the configs. the 2 routers are connected via a transfer ip net.

Client ip addresses are :

Client 1 z.B. 141.99.80.70

Client 2 z.B. 141.99.2.22, 141.99.131.100

the design is : h-core = Router 1, g-core = Router 2

i will add tomorrow addizional information

regards

Dietrich

Re: CE: layer2 redirect and GRE

Zach Seils — Tue, 22 Nov 2005 23:47:29 GMT

Thanks for posting the configurations. Where are the Client 2 IP addresses you listed coming from? I don't see that those addresses are directly connected to h-core. Is it possible this is just a routing issue? Can you provide the following from g-core:

sh ip ro 141.99.2.22

sh ip ro 141.99.131.100

regards,

Zach

Re: CE: layer2 redirect and GRE

dschleyer — Thu, 24 Nov 2005 08:31:28 GMT

Hello Zach,

customer sent me the output of the show commands:

G-Core#sh ip ro 141.99.2.22

Routing entry for 141.99.2.0/24

Known via "connected", distance 0, metric 0 (connected, via interface)

Routing Descriptor Blocks:

* directly connected, via Vlan2

Route metric is 0, traffic share count is 1

> sh ip ro 141.99.131.100

G-Core#sh ip ro 141.99.131.100

Routing entry for 141.99.131.0/24

Known via "static", distance 100, metric 0

Redistributing via ospf 254

Advertised by ospf 254 subnets

Routing Descriptor Blocks:

* 141.99.252.22

Route metric is 0, traffic share count is 1

In the config guide i didn´t understand the l2-redirection quite well.

Does l2 redirect insert the mac address of the ce as the destination address to avoid to establish a gre tunnel ? . Is that right ?

regards and thank you for your help

Dietrich

Re: CE: layer2 redirect and GRE

dschleyer — Thu, 24 Nov 2005 08:38:03 GMT

Hello Zach,

enclosed you find the network diagram made by my customer.

regards

Dietrich

Re: CE: layer2 redirect and GRE

dschleyer — Thu, 24 Nov 2005 13:24:29 GMT

Hello Zach ,

enclosed you find a nw drawing of the design.

Is it a good idea to configure the loopback address of the g-core switch in the router list of the ce ?

regards

Dietrich

Re: CE: layer2 redirect and GRE

Zach Seils — Sat, 26 Nov 2005 04:21:20 GMT

Dietrich,

Looking at the configuration on g-core-config, the redirect list used by WCCP is denying traffic sourced from 141.99.2.0/24 and 141.99.131.0/24. These two (2) entries would need to be removed from ACL 180 for traffic from these subnets to be redirected to the CE.

~Zach

Re: CE: layer2 redirect and GRE

dschleyer — Mon, 28 Nov 2005 07:14:48 GMT

Hello Zach,

customer told me, that if he deletes the entries in acl he has the problem which we are discussing:

client 1 can access the internet but

client 2 can´t access the internet

regards

Dietrich

Re: CE: layer2 redirect and GRE

Zach Seils — Mon, 28 Nov 2005 14:04:25 GMT

Can you please perform a trace route from client 2?

thanks,

Zach

Re: CE: layer2 redirect and GRE

dschleyer — Thu, 01 Dec 2005 06:11:28 GMT

Hello Zach,

i have asked my customer for the traceroute.

Another advie: customer told me that client 2 is an existent proxy-server. Could be that a problem ?

thank you for your help

regards

Dietrich

Re: CE: layer2 redirect and GRE

dschleyer — Thu, 01 Dec 2005 07:21:00 GMT

Which target ip -address is useful ? Any IP-Address in the interbnet?

regards

Dietrich

Re: CE: layer2 redirect and GRE

Zach Seils — Sat, 03 Dec 2005 23:07:28 GMT

Yes. Try one that works for client 1.

~Zach

Re: CE: layer2 redirect and GRE

dschleyer — Tue, 06 Dec 2005 14:39:07 GMT

Hello Zach,

i got a traceroutes from from the and one from Client 2 inot the internet::

Traceroute from 141.99.252.26 to 80.146.172.85 (80.146.172.85 isn't echoing)

ce#traceroute www.nk-networks.com

traceroute to 80.146.172.85 (80.146.172.85), 30 hops max, 38 byte packets

1 141.99.252.25 (141.99.252.25) 2.352 ms 0.305 ms 0.410 ms

2 ar-marburg3.x-win.dfn.de (188.1.16.20) 2.750 ms 3.155 ms 2.690 ms

3 188.1.18.10 (188.1.18.10) 6.607 ms 7.292 ms 8.055 ms

4 ar-goettingen3-te2-3.x-win.dfn.de (188.1.18.58) 7.890 ms 11.955 ms 9.891 ms

5 cr-hannover1.x-win.dfn.de (188.1.18.62) 6.354 ms 7.408 ms 6.474 ms

6 * 188.1.62.2 (188.1.62.2) 14.401 ms 16.609 ms

7 k-ea1.K.DE.net.DTAG.DE (62.154.55.158) 24.462 ms 26.855 ms *

8 80.148.148.67 (80.148.148.67) 13.904 ms 14.855 ms 15.960 ms

9 * * *

ce#

Traceroute from 141.99.2.22 to 80.146.172.85 (80.146.172.85 isn't echoing)

$ /usr/sbin/traceroute www.nk-networks.com

traceroute to www.nk-networks.com (80.146.172.85): 1-30 hops, 38 byte packets

1 141.99.2.254 (141.99.2.254) 0.976 ms 0.976 ms 0.0 ms

2 ar-marburg3.x-win.dfn.de (188.1.16.20) 2.93 ms 7.81 ms 4.88 ms

3 188.1.18.10 (188.1.18.10) 8.78 ms (ttl=249!) 10.7 ms (ttl=249!) 8.78 ms (ttl=249!)

4 ar-goettingen3-te2-3.x-win.dfn.de (188.1.18.58) 17.5 ms 4.88 ms 4.88 ms

5 cr-hannover1.x-win.dfn.de (188.1.18.62) 9.76 ms 8.78 ms 9.76 ms

6 188.1.62.2 (188.1.62.2) 14.6 ms 11.7 ms 7.81 ms

7 k-ea1.K.DE.net.DTAG.DE (62.154.55.158) 12.6 ms (ttl=246!) 18.5 ms (ttl=246!) 14.6 ms (ttl=246!)

8 80.148.148.67 (80.148.148.67) 35.1 ms (ttl=246!) 20.5 ms (ttl=246!) 13.6 ms (ttl=246!)

9 * * *

regards

Dietrich

Re: CE: layer2 redirect and GRE

Zach Seils — Fri, 09 Dec 2005 04:09:54 GMT

You mentioned previously:

"customer told me that client 2 is an existent proxy-server"

Are you saying that Client 2 is configured to use a proxy for web access? This would most certainly prevent the traffic from being redirected, assuming that the proxy port being used is something other than 80.

Does the client wish to continue using the proxy server?