isis bridging

Unanswered Question
Sep 10th, 2007


I have a hub-and-spoke topology where I want to implement isis functionality to the core router and bridging to all spoke ones (since they are not isis compatible), in order for those spoke ones to be transparent to hello messages exchanged between the core router and some other interior routers within each spoke router's site.

However, when allowing bridging of clns packets under the specified bridge group on all spoke routers, no clns/isis neighbors are established at all.

Is there something that I might be missing concerning the functionality of isis messages exchanged?

Thank you.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
paul.matthews Mon, 09/10/2007 - 06:49

This may be a tad more fundamental than that.

Is this a single core router with multiple end routers? How are the links configured? If you have bridging enabled on the core router to talk to the remote sites, and also have CLNS on the core router you may be hitting the issue that Cisco routers will not bridge a protocol they are configured to route.

I would suggest you either bridge everywhere(ugh!), look at IRB or look at ugrading the remote router to images that support ISIS.


panvangels Mon, 09/10/2007 - 07:30

Hi Paul,

- Each spoke link is a channel-group of E1 timeslots.

- Bridging for clns is not enabled on the core router, only on all spoke ones. For ip, routing is performed normally everywhere.

- Bridging everywhere is actually the current situation. However respective interfaces are almost overloaded.

- I think that upgrading the remote routers to support clns is not an option, since all of them are veeeery old (4000!).

In what way do you suggest me to look at IRB?

How is actually the format of isis messages exchanged? Are they clns encapsulated packets?

I'm asking because as SNPA in the core router is shown "HDLC", which I believe that might be incompatible with the ethernet bridging functionality of the remote routers' interfaces.

Thank you for your help,


paul.matthews Mon, 09/10/2007 - 07:48

If you are running 4000s, you want o be looking at replacing them anyway as they are getting rather long in the tooth!

ISIS message exhance is interesting - ISIS is the RP, where I presume what you are more interested in is the user traffic - out of interest what is the traffic?

As far as the traffic is concerned, on a LAN an ESH for example will just be a LAN packet, but the usual type field is probably length (IEEE 802.3) without any specific encapsulation. This IIRC are broadcast, and ISH frames are similar.

IRB means you can have kind of join the bridging and routing together - you can get the bridges traffic on the WAN to a BVI interface that has the routing config on it. That sorts out issues with encapsultion between the bridged traffic and the router.

Moving to routers that will support CLNS/ISIS means you can also ise ISIS as uyour IP routing protocol, meaning just one RP on the network, which has to be tidier!

Spyros.Pentzouris Tue, 09/11/2007 - 22:58


Concerning Paul's comments, why did you suggest IRB as the bridge solution and not crb? Do you think that this will help? The problem so far is that isis messages do not reach the far end router.

According to Panagiotis scenario, imagine three remote routers (three sites) where the middle one is the transparent one (does not support isis) and we need to pass ip and ip/clns traffic from two links to the far end router. This is the case somewhat. But this does not work.

So where do we need to enable irb? And you need bvi int on all three routers (supposing that 4000 series routers supports this feature)? Is there any problem with the encapsulation of the isis packets? Options of ctunnel, tunnel int also do not apply.

Can you be more specific of how such a scenario can be operational?



paul.matthews Tue, 09/11/2007 - 23:41

Any option like the IRB and CRB solutions is a bodge. The best solution is to scrap the 4000s and get something current that will support ISIS. That way you will have something that is supportable - I do hope the 4000s are not carrying anything important - if there are problems it will be difficult to get help.

Any mix of bridge the traffic here, route it there is always going to be troublesome and difficult to support.

The two *real* solutions are:

1. Upgrade and do it properly

2. Bridge it and if there are bandwidth issues either look at using bridge filter tables or buy more bandwidth.

panvangels Wed, 09/12/2007 - 02:21

Hi Paul,

I enabled IRB, but it seems there is an incompatibility problem with L2 encapsulations, since the one under the bvi interface is ARPA, and under the remote serial interface is HDLC.

The problem is boosted by the fact that there is no option within the bvi interface to change the encapsulation type.

Could you provide any suggestion?

Thank you,


paul.matthews Wed, 09/12/2007 - 02:27

Looks like you will need to go with the two options I mentioned earlier then - upgrade and do it properly or just bridge and buy more bandwidth.



This Discussion