phaqphaq

Right before “mov’ing /dev/myself to /var/home” I came along another odd thing on my border router.

An IPv6 peer was unreachable, i.e. did not respond to ICMP ping, as such the BGP session was down as well.
I gave it another indepth look as it happened to be one of our IPv6 upstream peers and had some sort of importance as such.

After talking to the NOC guy of the carrier, which assured that their interface was up, I was a bit confused.
He could neither PING my end, nor could I PING his end.


#ping ipv6 xxxxxxxxxx:80
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to xxxxxxxxxx:80, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)


I had however various IPv6 BGP sessions established within the same prefix, so it all seemed ok for the others.
For network guys not unusual is however to not only check L3 addressing but also inspect L2 addressing.

IPv4 techs use ARP (Address Resolution Protocol), which maps MAC (Media Access Control) to L3 IPv4 addresses.
However this doesn’t work, as ARP will only display MAC-IPv4 mappings (addresses obfuscated).


#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet xxxxxxxx.1 115 0000.0000.00fc ARPA GigabitEthernet0/3.110
Internet xxxxxxxxx.2 0 0000.0000.6a9a ARPA GigabitEthernet0/3.110


So, in the IPv6 world this is a little bit different, as ARP not strictly exists.
However, IPv6 uses something similar called “IPv6 neighbor discovery protocol (NDP)”.
The NDP status can be inspected using the “show ipv6 neighbors” command, which will give you a list of all IPv6 addresses and their MAC address counterparts:


#show ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
FE80::xxxxxxxxxxxxx:4000 0 0009.b766.4000 REACH Gi0/3.110
FE80::xxxxxxxxxxxxx:9C7D 87 000d.b918.9c7d STALE Gi0/3.111
FE80::xxxxxxxxxxxxx:2A80 0 001e.f7f6.2a80 REACH Gi0/3.110
FE80::xxxxxxxxxxxxx:AB79 0 0013.1937.ab79 STALE Gi0/3.111


You may also query a specific entry for a given IPv6 address:


#show ipv6 neighbors xxxxxxxxxxxxxxx:80
IPv6 Address Age Link-layer Addr State Interface
xxxxxxxxxxxxxxx:80 0 0000.0000.00fc STALE Gi0/3.110


As seen in this case, the address in question is in STALE state.
It is beyond the scope of this article to inspect all possiblbe reasons to why this happened.
A good starting place to inspect this is using the “debug ipv6 nd” command, which I may cover in another article.

The most obvious case is as simple as what seldomly happens with IPv4 ARP as well: the L3 and L2 addresses do not match up (maybe due to hardware exchange).

So, in the IPv4-world, you would do something like “clear arp” – but this won’t help with IPv6 NDP mismatches.
The simple solution is to clear the IPv6 ND cache:


#clear ipv6 neighbors


So, if this is really the root of the problem, you may notice a different L2 address afterwars:


#show ipv6 neighbors xxxxxxxxxxxxxxx:80
IPv6 Address Age Link-layer Addr State Interface
xxxxxxxxxxxxxxx:80 0 0000.0000.00ab REACH Gi0/3.110


In my case, the IPv6 peer was reachable by ICMP PING again and as such the BGP session recovered as well.

And now, finally, “mv /dev/myself /var/home/”

If you’re all too familiar with Cisco, then you will – as well as I do – struggle accross some weirdnesses on the Foundry/Brocade routers every now and then.

Not too long ago I fought around with a BGP issue on the XMR 4000.
My problem was that the XMR would announce just about any IPv6 prefix to all BGP peers, despite the fact that I had a configuration in place, which should effectifely only announce my own prefixes.

My Cisco configuration, which used to work properly, looks as shown below.
For the sake of simplicity I stripped away some advanced settings for communities, route-maps and prefix filters to keep it short.


ip as-path access-list 5 permit ^$
ip as-path access-list 5 deny .*
!
router bgp xxxxx
neighbor PEERGROUPv6 peer-group
neighbor PEERGROUPv6 description Some IPv6 Peers
!
neighbor SOMEIPV6PEER remote-as nnnnn
neighbor SOMEIPV6PEER peer-group PEERGROUPv6
!
address-family ipv6
neighbor PEERGROUPv6 soft-reconfiguration inbound
neighbor PEERGROUPv6 filter-list 5 out
!
neighbor SOMEIPV6PEER activate


The basic idea of this setup is to have all peers share the same subset of settings through the peer-group, in this case the filter-list, which should only permit my own AS.

On the cisco, this has this exact effect, causing only my prefixes to be announced to the peers:


#show bgp ipv6 uni neighbors MASKEDIPV6PEER advertised-routes
BGP table version is 6144418, local router ID is MASKEDROUTER
Status codes: s suppressed, d damped, h history, * valid, best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*iMASKEDIPV6PREFIX/32 MASKEDROUTER
1 100 0 i


Doing the same configuration 1:1 on the Brocade XMR didn’t work however. I always ended up having ALL IPv6 routes announced to my peers, no matter of their origin:


#show ipv6 bgp neigh MASKEDIPV6PEER advertised-routes
There are 8366 routes advertised to neighbor MASKEDIPV6PEER
Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST E:EBGP I:IBGP L:LOCAL
Prefix Next Hop Metric LocPrf Weight Status
1 2001::/32 MASKEDIPV6PEER
990 400 0 BI
AS_PATH: 6730 6695 12859
2 2001::/32 MASKEDIPV6PEER 301 0 E
AS_PATH: 6939
3 2001::/32 MASKEDIPV6PEER
999 100 0 E
AS_PATH: 13030 12859
4 2001:200::/32 MASKEDIPV6PEER
990 400 0 BI
AS_PATH: 6730 6939 2500
5 2001:200::/32 MASKEDIPV6PEER 980 300 0 E
AS_PATH: 6939 2500
6 2001:200::/32 MASKEDIPV6PEER
999 100 0 E
AS_PATH: 13030 2500


If course this is not what I intended, as only my local prefixes should be announced.
My initial Brocade config looked very similar to the Cisco config:


ip as-path access-list 5 seq 5 permit ^$
ip as-path access-list 5 seq 25 deny .*
!
router bgp
neighbor PEERGROUPv6 peer-group
neighbor PEERGROUPv6 description "Some IPv6 Peers"
!
neighbor SOMEIPV6PEER remote-as nnnnn
neighbor SOMEIPV6PEER peer-group PEERGROUPv6
!
address-family ipv6 unicast
neighbor PEERGROUPv6 activate
neighbor PEERGROUPv6 soft-reconfiguration inbound
neighbor PEERGROUPv6 filter-list 5 out
!
neighbor SOMEIPV6PEER activate


The main difference between Cisco and Brocade, despite from some syntactical differences, was the need to have the “neighbor PEERGROUPv6 activate” statement in place.
So if all routes are announced to all peers, a misconfiguration within the peer-group would be most likely the case. I checked the peer-group configuration as follows:


#show ip bgp peer-group
1 BGP peer-group is PEERGROUPv6
Description: Some IPv6 Peers
NextHopSelf: no
SoftInboundReconfiguration: yes
Address family : IPV4 Unicast
Route Filter Policies:
Filter-list: (out) 5
Address family : IPV4 Multicast
Address family : IPV6 Unicast
Filter-list: (out) 5
Prefix-list: (in) ipv6-prefix-in (out) ipv6-prefix-out
Route-map: (in) IXin (out) IXout
Address family : IPV6 Multicast
Members:
IP Address: MASKEDIPV6PEER, AS: MASKEDAS
IP Address: MASKEDIPV6PEER, AS: MASKEDAS
IP Address: MASKEDIPV6PEER, AS: MASKEDAS


This looked ok to me. It didn’t make any sense to me at all.

Well, I read the docs, but I didn’t find any reasonable clue on this. Also friend Google dind’t help.

After some time I had the idea to check what happens, if I add another “neighbor PEERGROUPv6 filter-list 5 out” command to the “address-family ipv4 unicast”, see below:


ip as-path access-list 5 seq 5 permit ^$
ip as-path access-list 5 seq 25 deny .*
!
router bgp
neighbor PEERGROUPv6 peer-group
neighbor PEERGROUPv6 description "Some IPv6 Peers"
!
neighbor SOMEIPV6PEER remote-as nnnnn
neighbor SOMEIPV6PEER peer-group PEERGROUPv6
!
address-family ipv4 unicast
neighbor PEERGROUPv6 filter-list 5 out
!
address-family ipv6 unicast
neighbor PEERGROUPv6 activate
neighbor PEERGROUPv6 soft-reconfiguration inbound
neighbor PEERGROUPv6 filter-list 5 out
!
neighbor SOMEIPV6PEER activate


Now I would need to reset the BGP peer to see if the change had an effect:


#clear ipv6 bgp neighbor SOMEIPV6PEER soft-outbound


I couldn’t believe it when I saw the result:


#show ipv6 bgp neigh MASKEDIPV6PEER advertised-routes
There are 1 routes advertised to neighbor 2001:7f8:24::aa
Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST E:EBGP I:IBGP L:LOCAL
Prefix Next Hop Metric LocPrf Weight Status
1 MASKEDIPV6PREFIX::/32 MASKEDROUTER 0 BE
AS_PATH: MASKEDAS


To see if I had done something wrong, I reverted all changes and tried again.
Result: Again all routes were announced.

Having reapplied the “IPv4 filter-list” again caused only required prefixes to be announced — exactly the way how I intended it.

Now, this doens’t make any sense at all and feels like a software bug within the implementation.
Even before adding this non-obvious configuration command, the output of “show ip bgp peer-group” clearly stated which filters and prefix lists the peer-group used.
The output didn’t change at all after applying the changed configuration.

At least my BGP announcements are correct now. The case still needs to be resolved with the Brocade tech guys.