02-24-2008 04:38 PM - edited 03-05-2019 09:20 PM
Hi everyone,
This has been on my mind for some time and I have done testing at the lab but I get stuck when I try to make tunnel interface member of bridge-group, that is simply NOT possible.
So instead I will give you the high level objective:
I have two LANs and there is IP connectivity between them via IP (public Internet, no circuits that I have control over so simple bridging is impossible)
I need to bridge those 2 LANs so the closest thing that came to mind was to create 2 new interfaces: BVI interface and tunnel gre interface, then make the tunnel interface and the ETH0 members of the same bridge-group as the BVI. Problem is that one can NOT assign bridge-group to tunnel interfaces.
Ultimately the test of success is whether I sit on one LAN and I can see arp on the other, pure bridging over IP
Is that possible?
~B
Solved! Go to Solution.
02-25-2008 04:15 AM
Hi
You can do this with L2TPv3 - see this link
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtl2tpv3.html
In short as an example from our lab
C1 (172.16.11.5) -> (fa0/1.11) R1 (fa0/0, 192.168.5.1) -> (fa0/0, 192.168.5.2) R2 (fa0/1.11) -> (172.16.11.7) C2
R1 Config
=========
R1(config)# pseudowire-class vconnect
R1(config-pw-class)# encapsulation l2tpv3
R1(config-pw-class)# ip local interface fa0/0
R1(config)# int fa0/1.11
R1(config-if)# encapsulation dot1q 11
R1(config-if)# xconnect 192.168.5.2 20 encapsulation l2tpv3 pw-class vconnect
R2 Config
=========
R2(config)# pseudowire-class vconnect
R2(config-pw-class)# encapsulation l2tpv3
R2(config-pw-class)# ip local interface fa0/0
R2(config)# int fa0/1.11
R2(config-if)# encapsulation dot1q 11
R2(config-if)# xconnect 192.168.5.1 20 encapsulation l2tpv3 pw-class vconnect
HTH
Jon
02-26-2008 01:29 AM
Boyan
1) C1 & C2 are not vlan aware as such, they are just 2 PC's connected into ports that have been allocated to vlan 11.
Does this answer your question ?
2) The virtual interface naming.
As with 802.1q encapsulation on a router interface the interface number does not matter but the "encapsulation dot1q
So it could have been
R1
int fa0/1.11
encapsulation dot1q 11
xconnect... etc
R2
int fa0/1.21
encapsulation dot1q 11
xconnect... etc
and it would still work. But if the "encapsulation dot1q
Jon
02-25-2008 04:15 AM
Hi
You can do this with L2TPv3 - see this link
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtl2tpv3.html
In short as an example from our lab
C1 (172.16.11.5) -> (fa0/1.11) R1 (fa0/0, 192.168.5.1) -> (fa0/0, 192.168.5.2) R2 (fa0/1.11) -> (172.16.11.7) C2
R1 Config
=========
R1(config)# pseudowire-class vconnect
R1(config-pw-class)# encapsulation l2tpv3
R1(config-pw-class)# ip local interface fa0/0
R1(config)# int fa0/1.11
R1(config-if)# encapsulation dot1q 11
R1(config-if)# xconnect 192.168.5.2 20 encapsulation l2tpv3 pw-class vconnect
R2 Config
=========
R2(config)# pseudowire-class vconnect
R2(config-pw-class)# encapsulation l2tpv3
R2(config-pw-class)# ip local interface fa0/0
R2(config)# int fa0/1.11
R2(config-if)# encapsulation dot1q 11
R2(config-if)# xconnect 192.168.5.1 20 encapsulation l2tpv3 pw-class vconnect
HTH
Jon
02-25-2008 11:28 AM
Thanks Jon
Do you really have two 7500/7200 series routers? I can't seem to find a way to run l2tp3 on a lower platform?
What hardware do you use in your lab?
02-25-2008 11:32 AM
Hi
One of the routers was a 7200 but the other was a 2621XM. The IOS on the 2621 was
c2600-spservicesk9-mz.123-4.T4.bin
I suspect, although i haven't checked that IP base or IP plus might not have L2TPv3. Check the feature navigator to be sure.
HTH
Jon
02-25-2008 11:51 AM
Perfect, got it to work on a cheap 1841 box I had laying around. Will be testing it soon and will post results.
The lowest one can get for Advance IP feature is 128M DRAM and 32M flash
c1841-advipservicesk9-mz.124-18.bin
You are correc, IP base and IP plus DO NOT have l2tpV3
Thanks
Boyan
02-25-2008 03:57 PM
Hey Jon
Could you explain in greater depth, how does C1 and C2 see the non-native vlan11? Those are just PCs connected to fa0/1 correct?
Also is the virtual interface naming significant? Is it just for clarity that you named fa0/1.11 to match vlan11?
02-26-2008 01:29 AM
Boyan
1) C1 & C2 are not vlan aware as such, they are just 2 PC's connected into ports that have been allocated to vlan 11.
Does this answer your question ?
2) The virtual interface naming.
As with 802.1q encapsulation on a router interface the interface number does not matter but the "encapsulation dot1q
So it could have been
R1
int fa0/1.11
encapsulation dot1q 11
xconnect... etc
R2
int fa0/1.21
encapsulation dot1q 11
xconnect... etc
and it would still work. But if the "encapsulation dot1q
Jon
03-16-2008 10:29 PM
Perfect
Thanks Jon. Things are working just as expected, sorry for the delayed answer.
Now I am onto my next interesting project - I wonder if I can use pseudo wire syntax and be able to map serial interfaces via IP - just as I bridged VLANs via IP I want to be able to bridge entire T1 spans preserving its signaling and so forth and then have the T1 span come out at the other end of the IP tunnel and be handled just as if it was present physically at the far end?
One item of interest here is how does one preserve the clocking? Obviuosly real clock encapsulation can't possibly be achieved via an IP tunnel so it has to be synthetically generated, I would guess, locally on both ends. Then there is the framing question - I want to keep using management streams that normally ride on the ESF "stealing" unused bits and althohgh 2-3Kbps at most, that is sufficient speed for non-GUI T1 span equipment management (Adtran and ADC are both utilizing these extra undocumented features). How would that be encapsulated into the pseudo wire and xconnect?
What do you think, too bold of a challange?
Thanks
Boyan
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: