From: gladston@br.ibm.com
Date: Fri Jul 01 2005 - 12:55:32 GMT-3
Have you seen this IOS problem?
I was configuring IPv6 basic connectivity over FR multipoint and there was no connectivity.
It was a scenario with other features configured.
After doing everything over and over, I erased all previous configuration from R2/R5, and typed command by command until loose connectivity.
For my surprise this command influences IPv6 connectivity:
'frame-relay map ip 172.16.200.5 205 broadcast IETF payload-compression FRF9 stac software'
It seems to be a bug, as this command clear related only to IPv4.
What do you thing?
(tough life this that besides learning the technology we need to learn Cisco bugs :) )
This is the config that works:
r2
interface Serial0/0.257 multipoint
ipv6 address FEC0:172:16:200::2/64
ip address 172.16.200.2 255.255.255.0
frame-relay map ipv6 FEC0:172:16:200::5 205 broadcast
frame-relay map ipv6 FEC0:172:16:200::7 207 broadcast
frame-relay map ip 172.16.200.5 205 br
But add this, and IPv6 stop works:
(R2 can not ping IPv6 address of R5 and vice-versa anymore; IPv4 works fine)
frame-relay map ip 172.16.200.5 205 broadcast IETF payload-compression FRF9 stac software
The remote end has similar configuration.
r5:
interface Serial0/0.200 multipoint
ip address 172.16.200.5 255.255.255.0
ipv6 address FEC0:172:16:200::5/64
frame-relay map ipv6 FEC0:172:16:200::2 502 broadcast
frame-relay map ipv 172.16.200.2 502 br
Adding this for compression, as done on R2:
frame-relay map ip 172.16.200.2 502 broadcast IETF payload-compression FRF9 stac software
Tests:
Before IPv4 compression
r2(config-subif)#do pi FEC0:172:16:200::5
!!!!!
After IPv4 compression
r2(config-subif)#$5 205 broadcast IETF payload-compression FRF9 stac software
r5(config-subif)#$ 502 broadcast IETF payload-compression FRF9 stac software
r2(config-subif)#do pi 172.16.200.5
!!!!!
r2(config-subif)#do pi FEC0:172:16:200::5
.....
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:29 GMT-3