From: crl (cisco@xxxxxxxxxxxx)
Date: Tue May 08 2001 - 21:27:21 GMT-3
Interesting, but I think you may have missed some of the thread. I've since
moved on, but never did find a complete explanation.
I'm not sure if I agree that SR/TLB is required, in this scenario. On the
token ring side I was running SRT, not SRB. So, for simplicity I was only
dealing with transparant bridging. (Perhaps the biggest tragedy of this
thread was that I named the subject field incorrectly!) Using transparant
bridging I had almost all types of IP traffic communicating over the TR/ETH
bridge. Yes, the bitswap-layer3-addresses command was needed. Or are you
saying that transparant bridging between TR(SRT) and Ethernet shouldn't
work? At least not reliably?
About multicast, my investigation led me to believe that the failure of this
scenario might not be easily blamed on multicast. I cannot make EIGRP/OSPF
work over the bridge, but RIPv2's multicasts were making it across without a
problem. Perhaps it is still multicast related, but that would only be half
the story...
For my final experiment (trick?) I configured NTP between the two endpoints
(that worked) and enabled detailed debugging. I worked with EIGRP for this,
but I suspect OSPF results would be similar. What I saw (and I pasted in the
debugs) was that EIGRP updates would make it across the bridge unscathed.
EIGRP hellos made it from Endpoint-A to Endpoint-B, but not vice-versa. So
Endpoint B thought he established an adjacency, but Endpoint-A did not list
anybody in his table. Further, when he received an update message, he would
complain about receiving an update from a neighbor he hadn't yet discovered.
Finally though, about the tunnel - this is most likely what I would have to
do. Excellent suggestion. If I encounter a situation like this in the lab, I
obviously can't afford to waste much time, hopefully I'll be allowed to
configure a tunnel and move on.
----- Original Message -----
From: "Wayne Gustavus" <wgustavus@mentortech.com>
To: "'crl'" <cisco@crl.fdns.net>; "'Johnny Dedon'"
<johnny.dedon@exodus.net>; "'Groupstudy'" <ccielab@groupstudy.com>
Sent: Tuesday, May 08, 2001 6:15 PM
Subject: RE: Translational Bridging between Token Ring and Ethernet, IRB,
and Various Routing Protocols
> Crl,
> I believe that both you and Johnny had part of the answer. First, Johnny
is
> correct when he states that you need SR/TLB to go between your ethernet
> domain and TR domain. Second, you are correct in stating that it is a
> multicast issue that is causing problems since no m/cast packets make it
> from the eth side through the SR/TLB process onto the TR (though they will
> flow in the other direction). Even after switching over to neighbor
> statments for the various routing protocols (RIPv2, EIGRP, OSPF) still
will
> not achieve the desired results.
>
> If you really have to do this (run routing protocols across a bridged core
> w/ SR/TLB), then I believe a tunnel is the only option. I can
successfully
> create an OSPF process and exchange routes in the scenario below. It
> requires a tunnel between R1 and R7. Note that I have some extra routers
in
> the middle b/c I don't have any TR/Eth routers, though this does not
matter.
>
>
> Lo0
> |
> R1---token---R2---serial---R4---ethernet---R7--lo0
>
>
> Notes:
> -R2 and R4 have no ip routing
> -R2 is performing SR/TLB
> -R4 is transparently bridging traffic between R2 and R7
> -R1 needs multiring ip
> -the tunnel is between R1 To0 and R7 E1
> -an OSPF adjcency forms between R1 and R7 over the tunnel
> -R1 and R7 can see OSPF routes for the other's loopback
>
> HTH,
>
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:30:36 GMT-3