Jump to content

ccierns2014circ

Members
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

7 Neutral

About ccierns2014circ

  • Rank
    Member
  1. So we have concluded the following for IPv6 Objective - 1. Do not change the ACL between R22 & R25, rather establish the tcp session between R22 & R25 via IPv4 and activate the neighborship under address-family ipv6 . 2. IPPhone ( Or MOBILE ) should not be enabled for ipv6 unicast-routing .(i.e. it is acting as an IPv6 Host ,and will receive RA messages via NDP & install default route) 3. We have to establish connectivity from the IPPhone to the interface connecting the Internet_Router and External_host .
  2. ccierns2014circ

    H1 MPLS

    Ohh god ! Lol , mistakenly I put that comment here . hahahaha , , I was reading some posts simultaneously . actually I wished to comment that here - [Hidden Content]
  3. SECTION 3.1 it is written , “ The ACME HQ network (AS12345) uses MPLS L3VPN in order to clearly separate remote site networks. The ACME corporate security policies are centralized and enforced at the San Jose site (AS 65112) for all remote sites. The policies require that all traffic that is originated from any remote sites (with the exception of New York office). “ the question is incomplete , it seems . Can you please complete this question ?
  4. ccierns2014circ

    H1 MPLS

    So we have concluded the following for IPv6 Objective - 1. Do not change the ACL between R22 & R25, rather establish the tcp session between R22 & R25 via IPv4 and activate the neighborship under address-family ipv6 . 2. IPPhone ( Or MOBILE ) should not be enabled for ipv6 unicast-routing .(i.e. it is acting as an IPv6 Host ,and will receive RA messages via NDP & install default route) 3. We have to establish connectivity from the IPPhone to the interface connecting the Internet_Router and External_host .
  5. ccierns2014circ

    H1 MPLS

    i guess you have formed a loop . Just do this , From router R99 ( AS30000 ) - traceroute 123.12.12.12 source 1.2.3.4 Let me know if u have a loop here .
  6. We already have the reachability from MOBILE To router R32, due to the policy routing implemented on R25 . Now ,for the return traffic from R32 to R25 , we must first of all inject R25's E0/0 prefix in to the bgp table using network command under bgp sub-config . After that is done , next step is to solve the next-hop issue . Now , R25 is pre-configured with a route-map with sets the ipv6 next-hop as R22 and this is correct for policy-routing to work . So, we would not change the route-map on R25 . Go to R22, here we see a route-map IPv6-NW on router R22 which has no set clause . Here , use this route-map to set the ipv6 next-hop to R25's serial 4/0 address, and apply it inbound on R22 . i.e. R22 will have a "neighbor 134.56.78.18 route-map IPv6-NW in" where the route-map IPv6-NW sets the next-hop to R25's serial4/0 address . But ,what I noticed is that , the ipv6 next-hop is shown always as inaccessible in the ipv6 unicast bgp table on router R22 ,even though the ipv6 address is reachable . OTHER ALTERNATIVE would be to use - Do not apply any route-map inbound on R22 towards R25 , Just use " no bgp default ipv6-nexthop " under bgp sub-config mode on router R25 . And the second option works .
  7. Yup bro ! You are right it . When I solved it , I didn;t face any issues but my friend faced the same one . its a bug in iou
  8. I solved this ticket and didn't face any issues . The data-plane was properly working . Security Associations established , and show crypto ipsec sa also depicted encryption/decryption going on fine . Host behind R19 could ping all other hosts . I guess, OzzieJat you too must have resolved the issue by now . Possible caveats - 1. R19 is NAT , so check for correct NAT config . i.e. inside , outside interface and the ip nat inside source list x int s4/0 overload . 2. U have already taken care for the access-list so that is not an issue . Let us know , if u still have any issues .
  9. Yes, there is dependency in lab ! You should bring up the EBGP neighborship between R17, R18, R19, --------- > AS10003 . Here , the underlay connectivity is VRF <whatever_name> and the overlay will be tunnel . So , UNDERLAY = VRF TABLE & OVERLAY = GLOBAL TABLE ! Implement , VRF Aware DMVPN to bring up the tunnel , normal config would not bring up the DMVPN tunnel .
  10. its a Security Parameter Index error bro ! The control plane is totally fine and IPsec Security Associations are already established . Without correct IPsec config , the Security Associations cannot be established . So there is no issue in IPsec config for sure . This error is in data-plane , and as OzzieJat said , it may be a iou limitation . Because what he is working on is " NAT Transparency aware IPsec " . By the way, OzzieJat can u please debug crypto ipsec and check whether the vendor-id and NAT-T capabilities are successfully negotiated ?
  11. Actually , crypto ipsec nat-transparency udp-encapsulation is enabled by default on CISCO IOS 12.2(3)T and later . So , it will not show that in the running-config , but no version of the command will . The error that you have posted in red color depicts a problem in the data-plane and not control-plane . Can you please post here the output of , show crypto ipsec sa on router R15 and the SPOKE ? There we must see unidirectional counters for the encap/decap of IPsec security associations .
  12. Ok ! So you are saying - 1. R15 HUB has EIGRP 200 2. All HUBS are running EIGRP 200 3. UNDERLAY IS EIGRP 145 . Please correct me , if I have interpreted something incorrect ! I posted this question because ccicert have given EIGRP 145 on the spokes and I strongly knew this was incorrect . Hence just needed to verify !
  13. Don't know why they have marked you zero in other sections but for nat , they have asked " should support multiple sessions " . So, you must have used the overload keyword while NAT . Anyway, still there is some terribly tricky part due to which netflow and ntp are marked wrong .
  14. Hi All , There is a ticket in the TS section where we are asked to accomplish the following - The user behind R15 ( i.e. PC103 ) should be able to reach the users behind R17,R18 & R19 via the DMVPN tunnel . Related topology is attached herewith the post . R15 is the HUB while R17,R18 and R19 are spokes . The question is - Which EIGRP Process are the Spokes running ? ? ? AS145 or AS200 ? So , we will have to run EIGRP on the tunnel accordingly !
  15. Keep both solutions at hand, One in which you can change acl and other in which you can't . I also didn't see that restriction , but when guru said , I gave it a thought and amended the second solution too . Adjust accordingly in the exam .
×
×
  • Create New...