Hi Xander,   For a 36x10G linecard which does not support ingress qos, how does VOQ works? Or how is it enabled?    Thanks, ... View more

Also, At the hub router of tunel 178, I see it is receiving nhrp regist request and sending back replyes. Seems that in transit this reply is lost... Any idea why? how to continue troubleshoot? R1# *Jun 27 12:32:02.415: NHRP: Receive Registration Request via Tunnel178 vrf 1, packet size: 105 *Jun 27 12:32:02.419:  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1 *Jun 27 12:32:02.423:      shtl: 4(NSAP), sstl: 0(NSAP) *Jun 27 12:32:02.427:      pktsz: 105 extoff: 52 *Jun 27 12:32:02.427:  (M) flags: "unique nat ", reqid: 65552 *Jun 27 12:32:02.431:      src NBMA: 172.16.254.2 *Jun 27 12:32:02.435:      src protocol: 178.178.178.21, dst protocol: 178.178.178.1 *Jun 27 12:32:02.443:  (C-1) code: no error(0) *Jun 27 12:32:02.443:        prefix: 32, mtu: 17916, hd_time: 360 *Jun 27 12:32:02.447:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0 *Jun 27 12:32:02.451: Responder Address Extension(3): *Jun 27 12:32:02.451: Forward Transit NHS Record Extension(4): *Jun 27 12:32:02.455: Reverse Transit NHS Record Extension(5): *Jun 27 12:32:02.455: Authentication Extension(7): *Jun 27 12:32:02.459:   type:Cleartext(1), data:claro *Jun 27 12:32:02 R1# R1# R1#.463: NAT address Extension(9): *Jun 27 12:32:02.463:  (C-1) code: no error(0) *Jun 27 12:32:02.467:        prefix: 32, mtu: 17916, hd_time: 0 *Jun 27 12:32:02.467:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0 *Jun 27 12:32:02.471:        client NBMA: 200.0.0.178 *Jun 27 12:32:02.475:        client protocol: 178.178.178.1 *Jun 27 12:32:02.487: NHRP: Send Registration Reply via Tunnel178 vrf 1, packet size: 125 *Jun 27 12:32:02.491:  src: 178.178.178.1, dst: 178.178.178.21 *Jun 27 12:32:02.499:  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1 *Jun 27 12:32:02.503:      shtl: 4(NSAP), sstl: 0(NSAP) *Jun 27 12:32:02.503:      pktsz: 125 extoff: 52 *Jun 27 12:32:02.507:  (M) flags: "unique nat ", reqid: 65552 *Jun 27 12:32:02.507:      src NBMA: 172.16.254.2 *Jun 27 12:32:02.511:      src protocol: 178.178.178.21, dst protocol: 178.178.178.1 *Jun 27 12:32:02.519:  (C-1) code: no error(0) *Jun 27 12:32:02.523:        prefix: 32, mtu: 17916, hd_ti R1#me: 360 *Jun 27 12:32:02.523:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0 *Jun 27 12:32:02.523: Responder Address Extension(3): Thanks, Carlos. ... View more

Hi Marcin, I made the following test using the debugs you suggested and I obtained the following results: 1. Initially both interfaces tunel 178 and tunel 179 are shutdown. Both are configured with if-state nhrp. 2. I enable (no shut) only the interface tunel 178. from the debug I see that for each nhrp registration request for int tun 178. there is a nhrp registration reply. *Jun 27 11:45:05.891: NHRP: Send Registration Request via Tunnel178 vrf 0, packet size: 105 *Jun 27 11:45:06.151: NHRP: Receive Registration Reply via Tunnel178 vrf 0, packet size: 125 3. I enable (no shut) interface tunel 179. from the debug I see that nhrp registrarion requests are still sent for int tunel 178, but I stop receiving nhrp registration replies for int tun 178. As there are no replies, the int tunel 178 changes state to up/down. *Jun 27 11:53:06.139: NHRP: Send Registration Request via Tunnel178 vrf 0, packet size: 105 *Jun 27 11:53:07.107: NHRP: Send Registration Request via Tunnel178 vrf 0, packet size: 105 *Jun 27 11:53:09.031: NHRP: Send Registration Request via Tunnel178 vrf 0, packet size: 105 *Jun 27 11:53:12.895: NHRP: Send Registration Request via Tunnel178 vrf 0, packet size: 105 *Jun 27 11:53:12.903:  src: 178.178.178.21, dst: 178.178.178.1 *Jun 27 11:53:12.911:  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1 *Jun 27 11:53:12.911:      shtl: 4(NSAP), sstl: 0(NSAP) *Jun 27 11:53:12.915:      pktsz: 105 extoff: 52 *Jun 27 11:53:12.919:  (M) flags: "unique nat ", reqid: 65552 *Jun 27 11:53:12.919:      src NBMA: 172.16.254.2 *Jun 27 11:53:12.923:      src protocol: 178.178.178.21, dst protocol: 178.178.178.1 *Jun 27 11:53:12.931:  (C-1) code: no error(0) *Jun 27 11:53:12.931:        prefix: 32, mtu: 17916, hd_time: 360 *Jun 27 11:53:12.935:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0 *Jun 27 11:53:12.935: Responder Address Extension(3): *Jun 27 11:53:12.935: Forward Transit NHS Record Extension(4): *Jun 27 11:53:12.935: Reverse Transit NHS Record Extension(5): *Jun 27 11:53:12.935: Authentication Extension(7): *Jun 27 11:53: R21#12.935:   type:Cleartext(1), data:claro *Jun 27 11:53:12.935: NAT address Extension(9): *Jun 27 11:53:12.935:  (C-1) code: no error(0) *Jun 27 11:53:12.935:        prefix: 32, mtu: 17916, hd_time: 0 *Jun 27 11:53:12.935:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0 *Jun 27 11:53:12.935:        client NBMA: 200.0.0.178 *Jun 27 11:53:12.935:        client protocol: 178.178.178.1 R21# *Jun 27 11:53:16.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel178, changed state to down R21# R21#show ip int brief Interface                  IP-Address      OK? Method Status                Protocol FastEthernet0/0            unassigned      YES NVRAM  administratively down down FastEthernet1/0            172.16.254.2    YES DHCP   up                    up FastEthernet1/1            unassigned      YES NVRAM  administratively down down Tunnel178                  178.178.178.21  YES NVRAM  up                    down Tunnel179                  179.179.179.21  YES NVRAM  up                    up R21#show ip nhrp nhs detail Legend: E=Expecting replies, R=Responding, W=Waiting Tunnel178: 178.178.178.1   E priority = 0 cluster = 0  req-sent 12  req-failed 0  repl-recv 7 (00:02:27 ago) Tunnel179: 179.179.179.1  RE priority = 0 cluster = 0  req-sent 1  req-failed 0  repl-recv 1 (00:00:56 ago) My question is, using my config, should I expect to receive reply for both tunnels? After live deployment, Im first testing using dynamips using the following version: R21#show ver Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.2(4)M3, RELEASE SOFTWARE (fc2) Thanks, Carlos. ... View more

Hi, Just want to know, if in the examples presented there was also tested H.A? (dual hub/dual dmvpn) and fast convergence? I have a similar setup like the one presented, with ebgp between hub and spokes. I want to test fast convergence once the main hub is down, but still not find any valid solution yet. I copy the link of the other threat that describes my problem. https://supportforums.cisco.com/message/3975776#3975776 Thanks, Carlos Trujillo. ... View more

Marcin, After deleting the command "if-state nhrp" from both tunnels, I see that one of the tunel changes it state to up/up and I can recover reachability to the remote hub. R21#show ip int brief Interface                  IP-Address      OK? Method Status                Protocol FastEthernet0/0            unassigned      YES NVRAM  administratively down down FastEthernet1/0            172.16.254.3    YES DHCP   up                    up FastEthernet1/1            unassigned      YES NVRAM  administratively down down Loopback0                  21.21.21.21     YES manual up                    up Tunnel178                  178.178.178.21  YES NVRAM  up                    down Tunnel179                  179.179.179.21  YES manual up                    up R21#config t Enter configuration commands, one per line.  End with CNTL/Z. R21(config)#int tun 178 R21(config-if)#no if R21(config-if)#no if-state nh R21(config-if)#no if-state nhrp R21(config-if)#int tun 179 R21(config-if)#no if-state nhrp R21(config-if)# *Jun 27 00:18:06.511: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel178, changed state to up R21(config-if)#^Z R21#show ip *Jun 27 00:18:16.103: %SYS-5-CONFIG_I: Configured from console by console R21#show ip int brief Interface                  IP-Address      OK? Method Status                Protocol FastEthernet0/0            unassigned      YES NVRAM  administratively down down FastEthernet1/0            172.16.254.3    YES DHCP   up                    up FastEthernet1/1            unassigned      YES NVRAM  administratively down down Loopback0                  21.21.21.21     YES manual up                    up Tunnel178                  178.178.178.21  YES NVRAM  up                    up Tunnel179                  179.179.179.21  YES manual up                    up R21#show ip nhrp nhs detail Legend: E=Expecting replies, R=Responding, W=Waiting Tunnel178: 178.178.178.1   E priority = 0 cluster = 0  req-sent 6  req-failed 0  repl-recv 0 (01:11:41 ago) Tunnel179: 179.179.179.1  RE priority = 0 cluster = 0  req-sent 1020  req-failed 0  repl-recv 522 (00:00:01 ago) R21# From the last output of "show ip nhrp nhs detail" I see only peer from tunel 179 is marked as RE: Responding, Expecting replies. Want to know why the peer from tunel 178 is not also in that state? I can ping both nbma (physical) and virtual (tunnel) ip address of both hubs. ########## Ping to hub 1 nbma (physical) address: R21#ping vrf dmvpn 200.0.0.178 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.0.0.178, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 200/303/436 ms ########## Ping to hub 2 nbma (physical) address: R21#ping vrf dmvpn 201.0.0.178 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 201.0.0.178, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 144/220/268 ms ########## Ping to hub 1 virtual (tunnel) address: R21#ping 178.178.178.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 178.178.178.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 164/186/228 ms ########## Ping to hub 2 virtual (tunnel) address: R21#ping 179.179.179.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 179.179.179.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 228/395/560 ms R21# R21#show ip nhrp nhs detail Legend: E=Expecting replies, R=Responding, W=Waiting Tunnel178: 178.178.178.1   E priority = 0 cluster = 0  req-sent 74  req-failed 0  repl-recv 0 (01:15:08 ago) Tunnel179: 179.179.179.1  RE priority = 0 cluster = 0  req-sent 1088  req-failed 0  repl-recv 590 (00:00:02 ago) R21# Thanks, Carlos Trujillo. ... View more

Marcin, I paste the config of one of the spokes. It has only one physical wan interface (attached to a vrf dmvpn, which is the "front vrf", and the global routing table acts as the "inside vrf" Both tunnels (one to hub1 and the other to hub2) use the same source interface fast 1/0. In the config I added the "if-state nhrp" command at each tunnel. R21#show run int tun 178 Building configuration... Current configuration : 408 bytes ! interface Tunnel178 ip address 178.178.178.21 255.255.255.0 no ip redirects ip mtu 1400 ip nhrp authentication XXX ip nhrp map multicast 200.0.0.178 ip nhrp map 178.178.178.1 200.0.0.178 ip nhrp network-id 178 ip nhrp holdtime 10 ip nhrp nhs 178.178.178.1 ip nhrp shortcut ip tcp adjust-mss 1360 if-state nhrp tunnel source FastEthernet1/0 tunnel mode gre multipoint tunnel vrf dmvpn end R21#show run int tun 179 Building configuration... Current configuration : 408 bytes ! interface Tunnel179 ip address 179.179.179.21 255.255.255.0 no ip redirects ip mtu 1400 ip nhrp authentication XXX ip nhrp map multicast 201.0.0.178 ip nhrp map 179.179.179.1 201.0.0.178 ip nhrp network-id 179 ip nhrp holdtime 10 ip nhrp nhs 179.179.179.1 ip nhrp shortcut ip tcp adjust-mss 1360 if-state nhrp tunnel source FastEthernet1/0 tunnel mode gre multipoint tunnel vrf dmvpn end After I added the command "if-state nhrp" at both tunnels, I saw one of the tunnels changed state from up/up to the up/down state, even when both hub routers (nhs´s) are reachable by the spoke. the interface change after adding the command is this the correct behavior? I want both tunnels to stay in up/up state when both hubs are reachable by the spoke. R21#show ip int brief Interface                  IP-Address      OK? Method Status                Protocol FastEthernet0/0            unassigned      YES NVRAM  administratively down down FastEthernet1/0            172.16.254.3    YES DHCP   up                    up FastEthernet1/1            unassigned      YES NVRAM  administratively down down Loopback0                  21.21.21.21     YES manual up                    up Tunnel178                  178.178.178.21  YES NVRAM  up                    down Tunnel179                  179.179.179.21  YES manual up                    up R21#show ip nhrp nhs detail Legend: E=Expecting replies, R=Responding, W=Waiting Tunnel178: 178.178.178.1   E priority = 0 cluster = 0  req-sent 600  req-failed 0  repl-recv 0 (01:06:28 ago) Tunnel179: 179.179.179.1  RE priority = 0 cluster = 0  req-sent 911  req-failed 0  repl-recv 413 (00:00:00 ago) Thanks, Carlos. ... View more

Richard/Joseph, Our design is also dual hub and each spoke has a tunel to each hub. As this is a service provider entry point to an mpls network (for internet routers), it is possible that it may grow to 400 spokes (almost same as your topology), or even more.. Due to the mixing vendors at each spoke and the possibility of large number of prefixes, we decided to use EBGP instead of an IGP (standard or propietary). We want to achieve fast convergence, but not overwhelming router  resources (memory/cpu) and avoid routing flap instabilitys due to  agressive timers. Questions: 1. If we decide to fine tune the EBGP timers, what could be the best values to start with? hello, dead interval? keeping in mind the large number of peerings (actually and in the future). 2. Of both solutions (use tuned gre keepalives, or tuned bgp timers) which is lighter (less cpu/memory cycles) in the hub router?  fast gre keepalives or more agressive hello dead bgp timers? Thanks, Carlos. ... View more

Thanks xander, i think we will modify the existing design so we can use up to 4 process at maximumw which will be: 3 process for ospf v2 (ipv4) 1 process for ospf v3 (ipv6) Achieving the maximum of 4 ospf process. Last questions: 1. Is it possible and "officially supported" to use in the same process the vrfs and also the default global table? They will keep isolated? 2. Apart from this document it is there any other cco document where I can find the information about this ospf process maximum support for the asr9k? Thanks, Carlos Trujillo ... View more

Yeah spell checker in iPhone works fine ;) Are there plans in the future for the test group to test a scenario with more than 4 process? It yes, could you ask when? Maybe is beyond the scope of this thread, want to know under what criteria the test was based in only 4 process? Why not more or even less? Im asking this because we are soon to replace some pe's in a big mpls network, and because the support now is "officially" supported to 4 process, we have to make some long term global changes in our network to support that ospf process limitation. Im thinking if maybe test group is soon going to test more process and if the results succed, we could keep our existing design. Mean our decission in how to continue depends of the answer of test group. Thanks for your clarification, Carlos Trujillo ... View more

Thanks for your reply, So even if it let me configure 7 ospf process, once I enable them say for example add neighbors and start learn lsas by each process, just 4 of them start to do ospf dutyes? The rest wont establish     Adjacencies and exchange lsas?  The 7 ospf process are the result of the conversion of an iOS device that will be replaced by an asr9k. Of the 7 process one is used for all the vrfs. The other 6 process are for services or domains attached to the default or global routing table + the core unicast/ multicast uplink process.  I know that it is possible to converge all the services (multiple domains) of the global table in a single process (single domain) but at the cost adding complexity like adding filters and in some cases even changing the entire area id of local and peer routers to keep the lsas away between services that with the asr9k will look as belonging to a single domain. Maybe that could be the justification pf using 7 process in our particular scenario? Thanks Carlos Trujillo ... View more

Hi xander, Regarding the number of ospf process, I can see a maximum of 10 ospf process can be configured in the box. Is there a recomendation or best Practice with the maximum number of ospf process to be configured in the box? For example if my design of a pe router with multiple routing instances in the global and vrf tables requires a total of 7 ospf process, is there a risk with the device resources consumption? The next question is when we must stop adding vrfs under a single ospf process? Is there a kpi or resource to monitor? If we are close to exceed that kpi, an alternative could be to use another ospf process and new vrfs attach to that new process? Thanks, Carlos Trujillo ... View more

Hi Xander, Do the asr9k platform has any type of restrictions regarding de number of DWDM XFPS present in a tengig linecard? Say for example, is fully supported a configuration with a 8x10G low queue line card, with 8x DWDM XFPs inserted? Want to stay sure the asr9k does not have any restrictions with the number of DWDM modules per linecard that the CRS still has. Thanks, Carlos Trujillo. ... View more