127-Bit IPv6 Prefixes on Inter-Router Links with EOS (S-Series)?

  • 0
  • 1
  • Question
  • Updated 11 months ago
  • Answered
  • (Edited)
Hi,

has anybody tried to implement /127 IPv6 transport networks with S-Series switches? Is some special configuration necessary for this to work?

The S-Series release notes list RFC 6164, Using 127-Bit IPv6 Prefixes on Inter-Router Links, as supported. I did not find any specific configuration advice in the manuals, GTAC Knowledge, or The Hub. Thus I simply configured a routable IPv6 address with /127 mask on the layer 3 interfaces, similar to using /31 networks with IPv4 (see RFC 3021). But after configuring the higher IPv6 address in the network, the switch answered to the lower IPv6 address as well, just as if the /127 network had a Subnet-router anycast address contrary to RFC 6164 section 6. This problem is described by RFC 3627Use of /127 Prefix Length Between Routers Considered Harmful, which has been move to Historic status by RFC 6547, section 3.

Is any special configuration needed to use /127 subnets on the S-Series?

(I have tried to use /127 subnets inside a VRF on S-Series switches with firmware 8.42.05.0003)
(At a first look /127 subnets seem to work on EXOS.)

Thanks,
Erik
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb

Posted 12 months ago

  • 0
  • 1
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,582 Points 10k badge 2x thumb
Why do you want to use > 64 bit mask for IPv6? I don't see a valid reason for that. Don't try to replicate the IPv4 logic to IPv6 addressing, it leads you to painful problem...
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb
Because the customer is always right. ;-)

Enough people see valid reasons for >64 bit prefix length to result in IETF workgroup adoption of relevant drafts and published RFCs. You might want to take a look at those RFCs to read about the reasons.

EOS is supposed to support this feature, thus I am wondering if this is a bug or not.
Photo of French, Luke

French, Luke, Employee

  • 712 Points 500 badge 2x thumb

RFC 6164 is supported, so this should work. I believe it is a   bug, can you open a case and include a show support and a trace showing the reply from the lower IP?

 

Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb
Hi Luke,

thanks for the info, a case will be opened.

The issue is easy to reproduce:

p3_sw3(su-router)->sho run
configure terminal
!
interface vlan.0.11
ipv6 address 2001:db8::1:0:0:0:11/127
ipv6 forwarding
no shutdown
exit
!
!
!
!

exit
!
p3_sw3(su-router)->ping 2001:db8::1:0:0:0:11
PING 2001:db8::1:0:0:0:11 (2001:db8::1:0:0:0:11) 64 bytes of data.
64 bytes from 2001:db8::1:0:0:0:11: icmp_seq=0 ttl=64 time=1.13 ms
64 bytes from 2001:db8::1:0:0:0:11: icmp_seq=1 ttl=64 time=0.484 ms
64 bytes from 2001:db8::1:0:0:0:11: icmp_seq=2 ttl=64 time=0.492 ms
64 bytes from 2001:db8::1:0:0:0:11: icmp_seq=3 ttl=64 time=0.488 ms

--- 2001:db8::1:0:0:0:11 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2996 ms
rtt min/avg/max = 0/0/1 ms
p3_sw3(su-router)->ping 2001:db8::1:0:0:0:10
PING 2001:db8::1:0:0:0:10 (2001:db8::1:0:0:0:10) 64 bytes of data.
64 bytes from 2001:db8::1:0:0:0:11: icmp_seq=0 ttl=64 time=1.71 ms
64 bytes from 2001:db8::1:0:0:0:11: icmp_seq=1 ttl=64 time=1.50 ms
64 bytes from 2001:db8::1:0:0:0:11: icmp_seq=2 ttl=64 time=1.53 ms
64 bytes from 2001:db8::1:0:0:0:11: icmp_seq=3 ttl=64 time=1.57 ms

--- 2001:db8::1:0:0:0:10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002 ms
rtt min/avg/max = 1/1/1 ms
p3_sw3(su-router)->show ipv6 interface vlan.0.11

vlan.0.11 is Operationally up, Administratively up
IPv6 is enabled, link-local address is fe80::21f:45ff:fe9b:32fa%11
Global unicast address(es):
2001:db8::1:0:0:0:11, subnet is 2001:db8::1:0:0:0:10/127 [Management]
Joined group address(es):
ff02::1
ff02::1:ff00:0
ff02::1:ff9b:32fa
ff02::2
ff02::1:ff00:10
ff02::1:ff00:11
IPv6 forwarding enabled
IPv6 address auto-configuration is disabled
IPv6 Dhcp Relay Address(es): Not Set
Incoming IPv6 Access list is not set
Outgoing IPv6 Access list is not set
ICMP error messages limited to one every 100 milliseconds
Sending of ICMP Destination Unreachable Messages is enabled
Sending of ICMP Redirect Messages is enabled
Sending of ICMP Echo-Reply Messages is enabled
IPv6 Policy Routing is disabled
ND DAD is enabled, number of DAD attempts: 1
ARP/ND proxy all is disabled
ND Router Preference is Medium
ND advertised reachable time is 0 milliseconds
ND advertised flags: managed = Off other-config = Off
ND advertised Neighbor Solicitation transmit interval is 0
ND MTU is not advertised
ND router advertisements are sent every 198 to 600 seconds (next one in 224 seconds)
ND router advertisements live for 1800 seconds
Advertising Prefixes:
2001:db8::1:0:0:0:10/127 on-link auto-config valid for 2592000 seconds preferred for 604800 seconds
PIM Sparse-mode is disabled
p3_sw3(su-router)->show ipv6 neighbors
FLAGS: I = Incomplete R = Reachable
S = Stale D = Delay
P = Probe L = Local
F = Fixed (Static) H = Host Interest
V = VRRP 2 = Secondary VLAN
M = Main Router A = Proxy-All Entry
X = VxLan # = VxLan Remote

Note: Additional information is available by using the 'verbose' option or by
increasing the size of your terminal columns to 116 (use 'set width')

Ipv6 Address Hardware Address Flg Interface
--------------------------------------- ----------------- --- --------------
2001:db8:0:1:0:0:0:11 00-1f-45-9b-32-fa LR vlan.0.11
fe80:0:0:0:21f:45ff:fe9b:32fa 00-1f-45-9b-32-fa LR vlan.0.11
--------------------------------------- ----------------- --- --------------
Neighbor Entries Found: 2


Thanks,
Erik
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 12,582 Points 10k badge 2x thumb
Sorry, can't help on the feature supported or not.

For the "customer is always right", I disagree here. This is more about ignorance with IPv6 and habits from IPv4, and that's actually the reason for the RFCs you cited, explain to users why you don't have to do it.

On many merchand silicon, using >64bit will lead you into (unnecessary) problem on a network. The Coreflow2 is far better in that aspect, so in your position that might be a non issue. But not every product is like an S-Series.
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 12,782 Points 10k badge 2x thumb
Hi Stephane,

you are correct that the forwarding tables of the S-Series CoreFlow2 are better suited for >64 bit prefix length than those of Broadcom chips. Additional tests suggest that EXOS has better software support for OSPFv3 and longer prefixes than EOS, but my testing was not exhaustive at all.

Thanks,
Erik