I currently have a Nexus 7000 (n7000-s2-dk18.104.22.168.bin) that is trying to communicate with an ASR 1001-x (v03.16.07b.S). Both IPv4 and IPv6 are configured on the two routers. OSPFv2 handshakes without issues whereas OSPFv3 gets stuck on the Nexus in the EXSTART state (constantly cycles back to INIT, etc). ASR1001-x interface TenGigabitEthernet0/0/0.116 encapsulation dot1Q 116 ip address xxx.xxx.88.211 255.255.255.240 standby version 2 standby 116 ip xxx.xxx.88.209 standby 116 authentication md5 key-string xxxxxxxxxx ipv6 address FE80::116:102 link-local ipv6 address xxxx:xxxx:130:1::102/64 ipv6 enable ospfv3 101 priority 25 ospfv3 101 ipv6 area 0 router ospf 101 log-adjacency-changes detail network xxx.xx.88.208 0.0.0.15 area 0 network xxx.xxx.103.24 0.0.0.7 area 0 network xxx.xxx.103.251 0.0.0.0 area 0 router ospfv3 101 address-family ipv6 unicast log-adjacency-changes detail exit-address-family NEXUS7000 interface Vlan116 vrf member tower_net ip address xxx.xxx.88.219/28 ipv6 address xxxx:xxxx:130:1::1eaf:101/64 ipv6 link-local fe80::116:199 ip ospf cost 10 ip router ospf 101 area 0.0.0.0 ospfv3 cost 10 no ospfv3 passive-interface ipv6 router ospfv3 101 area 0.0.0.0 no shutdown router ospf 101 vrf tower_net network xxx.xxx.88.208/28 area 0.0.0.0 network xxx.xxx.100.0/24 area 0.0.0.0 network xxx.xxx.103.252/32 area 0.0.0.0 log-adjacency-changes detail router ospfv3 101 vrf tower_net log-adjacency-changes detail address-family ipv6 unicast Looking at the states for both OSPFv2 and OSPFv3 on the nexus, we get: core-sv7-nexus1# sho ip ospf neighbors vrf tower_net OSPF Process ID 101 VRF tower_net Total number of neighbors: 3 Neighbor ID Pri State Up Time Address Interface xxx.xxx.20.10 1 FULL/DROTHER 22w0d xxx.xxx.88.218 Vlan116 xxx.xxx.103.250 1 FULL/BDR 34w1d xxx.xxx.88.210 Vlan116 xxx.xxx.103.251 1 FULL/DROTHER 33w0d xxx.xxx.88.211 Vlan116 core-sv7-nexus1# sho ospfv3 vrf tower_net nei OSPFv3 Process ID 101 VRF tower_net Total number of neighbors: 3 Neighbor ID Pri State Up Time Interface ID Interface xxx.xxx.103.248 1 TWOWAY/DROTHER 00:02:28 7 Vlan116 Neighbor address fe80::116:901 xxx.xxx.103.250 25 EXSTART/BDR 00:02:37 27 Vlan116 Neighbor address fe80::116:101 xxx.xxx.103.251 25 EXSTART/DR 00:02:28 24 Vlan116 Neighbor address fe80::116:102 Have verified with both IPv4 and IPv6 that my MTUs are not mismatched (tried using ignore-mtu as well with no change). Looking at the logs on a particular handshake (its the same for all of them, just focusing on one for clarity) I get the following repeating over and over when talking to the non-BD/BDRs: 2020 Feb 7 17:30:09 core-sv7-nexus1 %OSPFV3-5-NBRSTATE: ospfv3-101  Process 101, Nbr xxx.xxx.103.250 on Vlan116 from EXSTART to INIT, ONEWAYRCVD 2020 Feb 7 17:31:16 core-sv7-nexus1 %OSPFV3-5-NBRSTATE: ospfv3-101  Process 101, Nbr xxx.xxx.103.250 on Vlan116 from INIT to EXSTART, ADJOK 2020 Feb 7 17:33:19 core-sv7-nexus1 %OSPFV3-5-NBRSTATE: ospfv3-101  Process 101, Nbr xxx.xxx.103.250 on Vlan116 from EXSTART to INIT, ONEWAYRCVD and talking to the DR/BDR I get the following (repeating over and over): 2020 Feb 7 17:30:09 core-nexus1 %OSPFV3-5-NBRSTATE: ospfv3-101  Process 101, Nbr xxx.xxx.103.248 on Vlan116 from TWOWAY to TWOWAY, ADJOK 2020 Feb 7 17:30:12 core-nexus1 %OSPFV3-5-NBRSTATE: ospfv3-101  Process 101, Nbr xxx.xxx.103.248 on Vlan116 from TWOWAY to EXSTART, ADJOK 2020 Feb 7 17:31:18 core-nexus1 %OSPFV3-5-NBRSTATE: ospfv3-101  Process 101, Nbr xxx.xxx.103.248 on Vlan116 from EXSTART to TWOWAY, ADJOK After a couple days, I'm completely lost. At this point figured I'd ask around to see if anyone else knows or has seen this with OSPFv3...
... View more
So I did a couple experiments and your method *did* work when there are only a couple routers involved. The bigger problem is when you have a rather large OSPF network and you turn on authentication to begin with. Even if no password is defined yet, the connections break when you turn on authentication... and the breakage spreads throughout your network. I have been unable to come up with a way to turn on authentication across a >100 router network without huge sections going dark for long periods of time (which isn't acceptable). So I'm trying to come up with something better. At first I tried just turning on authentication without passwords, intending to do that on a per interface basis (which is still difficult when there are 10+ routers on a few segments). So far I haven't figured out a reasonable transition mechanism. Anyone else have any better suggestions that deal with real world networks and not a PtP lab experiment? Marcos
... View more
So I'm trying to go through the release notes and figure out the primary differences. I still can't quite make heads or tails out of it. This month, both Denali and Everest are marked with the (star) (both in MD status) whereas the 3.x series is no longer recommended. I'm currently running 3.16.7bS(MD) and was about to get 3.16.8S(MD) but noticed that it was released back in 10-Aug-2018 whereas all the 16 series are Mar-2019. Is the 3 branch dead? Should I be thinking of upgrading? what do I gain/lose if I upgrade? These are being used currently as BGP peering routers so the only protocols I really run on them are BGP, OSPF, tons of route-maps, and about 10-30 peering sessions per ASR. (rather minor bogon access-list filters). Marcos
... View more
That doesn't actually give you all the possible routes. Only gives you the routes that your routers accepted with the best possible cost... For instance, using the "show ip ospf rib" as suggested gives me the following for a particular route:
*> 22.214.171.124/24, Intra, cost 1163, area 0 via 126.96.36.199, GigabitEthernet0/1.95 via 188.8.131.52, GigabitEthernet0/0
I do however know for a fact that there is a more "expensive" cost route coming in via my GigabitEthernet 0/0.88 interface which is not being displayed as the calculated cost should have been around 1263 rather than the 1163 in the RIB.
So that doesn't actually answer his question above (or mine which is how I found this thread).
... View more
Not sure how this would be helpful information as it doesn't give me any new information. I already had that for the 15.0 series (I'm running 15.2 as stated originally) so I have no new references to validate against. Also it appears no one from Cisco IPv6 group actually reads these things either. Marcos
... View more
So I have a series of customers that all have various manufacturers of dual stack home routers. They are picking up both IPv4 and IPv6 addresses from me as well as a PD (prefix delegation) for their internal network (typically a /64, sometimes a /56). I am using the ISC KEA DHCPv4/v6 server on my back end.
I've tested the DHCP server and its correctly analyzing the packet requests and sending both an IPv6 address and IPv6 PD (as well as other information) back to the requesting router. The CE-Router (currently a Cisco 7301 IOS 15.2(4)M11 [c7301-adventerprisek9-mz.152-4.M11.bin]) is giving the correct information to the client however the router is NOT inserting a static route into its routing table for the allocated PD. Same behavior both with and without IPv6 traffic-filters
Note: A-flag off w/prefix, M-flag on, O-flag off,
Config on the CE-Router
ipv6 general-prefix tower-sjc 2604:xxxx:xxxx:1::/64
ipv6 unicast-routing ipv6 cef ipv6 dhcp iana-route-add
interface GigabitEthernet0/1.121 description ::Tower CE (v121) encapsulation dot1Q 121 ip dhcp relay information option-insert ip dhcp relay information check-reply ip address xxx.xxx.xxx.2 255.255.254.0 ip access-group CE-inbound in ip access-group CE-outbound out ip helper-address xxx.xxx.xxx.xxx standby version 2 standby 121 ip xxx.xxx.xxx.1 standby 121 priority 105 standby 121 preempt standby 121 track 2 decrement 10
! This is our HSRP link-local address on this interface standby 221 ipv6 FE80::121:1 standby 221 priority 105 standby 221 preempt delay minimum 30 standby 221 track 2 decrement 10 ip ospf cost 10
! Set link-local to indicate VLAN and router number ipv6 address FE80::121:2 link-local ipv6 address tower-sjc ::1/64 ipv6 enable
! Turn off the A flag (but still advertise the prefix) ipv6 nd prefix 2604:xxxx:xxxx:1::/64 no-advertise
! Turn on the M flag (for managed configuration via stateful DHCPv6) ipv6 nd managed-config-flag
! Relay to stateful DHCPv6 server ipv6 dhcp relay destination 2604:xxxx:xxxx:xxxx::FEED:200 ipv6 traffic-filter CE-IPv6-inbound in ipv6 traffic-filter CE-IPv6-outbound out ipv6 ospf 101 area 0 ipv6 ospf priority 0 no keepalive
So I've been experimenting with this and the "ipv6 dhcp iana-route-add" statement is supposed to work based on all the documentation I could find (which then allows for propigation in your IGP) however experimenting and testing shows that its not in fact working. Unless there is an error in the configuration I'd say this is a broken command from Cisco IOS
... View more
There currently is no such thing as a 6-byte AS number. Prior to 2007, AS numbers were 2-byte (or 16 bit) numbers ranging from 0-65535 where some of those were reserved for private use (ie, not to be used on the actual internet). Just like IP addresses however, there was a push to expand the number of AS numbers available as the usage continued to go up. So another RFC was published to push AS numbers from 16 bits to 32 bits (2-byte to 4-byte). Since around 2010, IANA has been issuing 32bit AS numbers rather than the older 16bit numbers. Representation of these numbers look as follows: For original 16bit AS number (like my personal one) AS-Plain: 4432 AS-Dot: 0.4432 For newer 32bit AS numbers, you might see something like: AS-Plain: 65560 AS-Dot: 1.24 (where you computed 1 * 65536 + 24 = 65560) ... To use your router in "AS-Dot" notation, you need to use the command "bgp annotation dot" then you can use the dot notation in your BGP commands. Be aware that cisco uses "10.1" as an example ASN however they often miswrite what the AS-Plain version of that is (its really a bad example). AS-Dot: 10.1 = 10 * 65536 + 1 = 655361 (which when written can be confusing if miswritten) --- quick example: if your ASN (AS-Plain) was 66123, then your AS-Dot would be (1 * 65536 + 587) or 1.587 bgp router 1.587 no synchronization bgp router id 184.108.40.206 bgp annotation dot bgp log-neighbor-changes ...etc... Marcos (BGP Engineer since 1992)
... View more
This is a rather old post however it keeps coming up in google so just in case someone else was wondering... DNS port 53 (udp) is for a client to query a server. This is the standard method of pulling down a single query from a DNS server and is by far the most commonly used form of DNS DNS port 53 (tcp) is used for server-to-server communications (typ) when one server is requesting a zone transfer of the entire zone. Typically this is seen from slave servers to their masters (or hidden masters depending on how the org is set up). Note that (tcp) is typically denied with a white list of servers that are allowed to make queries whereas (udp) is typically allowed with potentially a black list of servers that are "bad guys".
... View more