[c-nsp] 12.2.33SRA: eompls vs. ospf ?

Alexandre Snarskii snar at paranoia.ru
Fri Dec 15 08:08:54 EST 2006


On Thu, Dec 14, 2006 at 06:09:12PM +0300, Alexandre Snarskii wrote:
> 
> Hi!
> 
> Yesterday we migrated one of our routers (6500/Sup720/pfc3bxl) 
> from 12.2(17d)SXB11 to 12.2(33)SRA1, reconfigured client's 
> eompls connection from SVI-based to Subinterface/MUX-UNI-based, 
> and everyting seemed to work... Before client argued that his 
> OSPF stopped to work over his eompls circuit, while unicast data 
> still works well :( 
> 
> Configuration is trivial enough, before migration it was
> 
> int vlan NNN
>  xconnect A.B.C.D NNN encapsulation mpls
> after migration: 
> int poA.NNN
>  xconnect A.B.C.D NNN encapsulation mpls
> 
> Any ideas why OSPF may stop to work over eompls ? 
> Interworking type is ethernet, so, all ethernet frames should 
> be transmitted from one end to another, even without mac-learning..

Tested this behaviour in lab.

Setup: HostA - RouterA - ge/mpls/ip - RouterB - HostB

Both routers are 6509/Sup720/pfc3bxl, the main difference is that
RouterA runs "old" 12.2.17d-SXB11 ios, while RouterB is upgraded to
12.2.33-SRA1. Another difference is that interface on RouterA is the
GE-WAN port on OSM-4GE-WAN, and on RouterB it's GigabitEthernet (LAN)
on 6516.

Both hosts are FreeBSD 6.2-PRE, running openospfd and my own program
to test multicast connectivity.

Results:

Multicast/UDP frames passed over EoMPLS circuit well, even when using
224.0.0.5 (OSPF-ALL) group address, used for OSPF Hellos.

Multicast/OSPF frames passed over EoMPLS circuit in only one direction - 
from RouterA to RouterB, so ospf process on HostA does not see neighbor
on HostB at all, while ospf on HostB receives hellos from HostA, but
session never goes farther than INIT/WAIT or INIT/DROTHER state.

The only difference between Multicast/UDP/224.0.0.5 and Multicast/
OSPF-Hello/224.0.05 packets is the IP-Protocol value in IP header, so, 
I can assume only that new IOS takes this field into account, despite 
the fact that EoMPLS should pass all layer2 frames intact.

Bug ? Feature ? 

PS: another our customer complained that his EIGRP stopped work too.
So, may be not only OSPF affected..



More information about the cisco-nsp mailing list