Lab 4, label problem

IN Lab4, to setup InterAS peering for VPNv4, VPNv6 and MDT, I am trying to get label swtiching between XR10 and R4.  I am using online Remote Lab.  I could not get ebgp peering between R4 and XR2. R4 and XR2 can't communicate.  ping and traceroute failed. At that time, I used bgp send-label for Inter and Intra.  Actually, I worked on 1st day. I failed starting on 2nd day. On 1st day, I can traceroute and I could see MPLS label.  But, starting next day, I could not trace but I can see label.

Finally, I choosed the same method of workbook.  I redistribute bgp routes into ISIS.  I noticed I get remote label (AS2000) via R5 but I can't get via XR1.  If I shut down link of XR1 to R3, I can see all labels via R5.  As I am redistributing into IGP, all routers have all routes. So, I can communicate between XR2 and R4 but it is not label switching if XR1 is on the way.

I tried several time but still can't.  Is there any other method I can troubleshooot?  I don't know why I can't get label via XR1.

Comments

  • Do you have your configs still or any output?

  • HI khine,

    I replied earlier but nothing had appeared, not sure what's happening with my posts. Maybe they are too rubbish for human eyes :)

    Anyway do you have the configs still?  Or some output, hard to figure it out from what you have posted.

  • Yes, I still have config.  I tested it on INE remote lab.  If you like to test, you can use my attached file.  I hope you will get this file.

    [View:/cfs-file.ashx/__key/CommunityServer.Components.UserFiles/00.00.02.37.18/2013.09.21_2D00_S2_2D00_10.32_2D00_sprack5.zip]

  • I believe this is between XR2 and R4, yes? When you configure ebgp-multihop for the R4 peer on XR2, does it install a Pop for 10.0.0.4 towards XR1? If so you'll  need to use the ebgp multihop mpls command. This is needed since XR2 is both VPNv4 RR and passing traffic.

  • I tried to upload my config file but it seems not allowing.  Here is some part of XR1 configure.  XR2 can get label and go via R5 if I shut interface of XR1 to R3.  That means, I felt XR1 config or something connectivity to R3 might be wrong.

    XR1:
    route-policy REDIS-BGP-2-ISIS
      if destination in REMOTE-LO then
        pass
      endif
    end-policy
    !
    router static
     address-family ipv4 unicast
      10.0.193.3/32 GigabitEthernet0/1/0/0.193
     !
    router isis 1000
     is-type level-2-only
     net 49.0019.0000.0000.0019.00
     address-family ipv4 unicast
      metric-style wide
      mpls traffic-eng level-2-only
      mpls traffic-eng router-id Loopback0
      redistribute bgp 1000 route-policy REDIS-BGP-2-ISIS
      mpls ldp auto-config
     !
    router bgp 1000
     bgp router-id 10.0.0.19
     address-family ipv4 unicast
      network 10.0.0.19/32
      allocate-label all
     !
     address-family vpnv4 unicast
     !
     address-family ipv6 unicast
      network 2001:10::19/128
     !
     address-family vpnv6 unicast
     !
     address-family ipv4 mdt
     !
     neighbor 10.0.0.2
      remote-as 1000
      update-source Loopback0
      address-family ipv4 unicast
       next-hop-self
      !
     !
     neighbor 10.0.0.20
      remote-as 1000
      update-source Loopback0
      address-family vpnv4 unicast
      !
      address-family vpnv6 unicast
      !
      address-family ipv4 mdt
      !
     !
     neighbor 10.0.193.3
      remote-as 2000
      address-family ipv4 labeled-unicast
       send-community-ebgp
       route-policy RFC1998 in
       route-policy PASS out
      !
     !
     vrf FOO
      rd 10.0.0.19:1
      address-family ipv4 unicast
       network 172.16.0.19/32
      !
      address-family ipv6 unicast
       network 2001:172:16::19/128
      !
     !
    mpls ldp
     router-id 10.0.0.19

     

  • I believe this is between XR2 and R4, yes? When you configure ebgp-multihop for the R4 peer on XR2, does it install a Pop for 10.0.0.4 towards XR1? If so you'll  need to use the ebgp multihop mpls command. This is needed since XR2 is both VPNv4 RR and passing traffic.

     

    I need to try this...I had this same problem that I wrote about before. The way that it was "fixed" was by adding "next-hop unchanged" on XR2's VPNv4 eBGP session to R4. For whatever weird reason IOS-XR does this behavior. Can you please look at my post and see if this is what you are referring to? I would really like to get an answer to this IOS-XR mystery!

    Here is the post:

    http://ieoc.com/forums/t/27055.aspx

     

    Pablo

     

  • I pasted configuration of XR2.  I don't beleive this is not XR2 problem.  As it worked well if goes via R5.  I can't get label of AS2000 routers from XR1.

    !XR2
    router bgp 1000
     bgp router-id 10.0.0.20
     address-family ipv4 unicast
      network 10.0.0.20/32
      allocate-label all
     !
     address-family vpnv4 unicast
     !
     address-family ipv6 unicast
      network 2001:10::20/128
     !
     address-family vpnv6 unicast
     !
     address-family ipv4 mdt
     !
     neighbor 10.0.0.2
      remote-as 1000
      update-source Loopback0
      address-family ipv4 unicast
      !
      address-family vpnv4 unicast
       route-reflector-client
      !
      address-family vpnv6 unicast
       route-reflector-client
      !
      address-family ipv4 mdt
       route-reflector-client
      !
     !
     neighbor 10.0.0.4
      remote-as 2000
      ebgp-multihop 255
      update-source Loopback0
      address-family vpnv4 unicast
       route-policy PASS in
       route-policy PASS out
       next-hop-unchanged
      !
      address-family vpnv6 unicast
       route-policy PASS in
       route-policy PASS out
       next-hop-unchanged
      !
      address-family ipv4 mdt
       route-policy PASS in
       route-policy PASS out
      !
     !
     neighbor 10.0.0.5
      remote-as 1000
      update-source Loopback0
      address-family vpnv4 unicast
       route-reflector-client
      !
      address-family vpnv6 unicast
       route-reflector-client
      !
      address-family ipv4 mdt
       route-reflector-client
      !
     !
     neighbor 10.0.0.19
      remote-as 1000
      update-source Loopback0
      address-family vpnv4 unicast
       route-reflector-client
      !
      address-family vpnv6 unicast
       route-reflector-client
      !
      address-family ipv4 mdt
       route-reflector-client
      !
     !
     neighbor 2001:10::19
      remote-as 1000
      update-source Loopback0
      address-family ipv6 unicast
      !
     !
     vrf FOO
      rd 10.0.0.20:1
      address-family ipv4 unicast
       network 172.16.0.20/32
       allocate-label all
      !
      address-family ipv6 unicast
       network 2001:172:16::20/128
      !
      neighbor 172.16.207.7
       remote-as 3000
       address-family ipv4 labeled-unicast
        route-policy PASS in
        route-policy PASS out
       !
      !
      neighbor 172.16.208.8
       remote-as 3000
       address-family ipv4 labeled-unicast
        route-policy PASS in
        route-policy PASS out
       !

  • My config includes 'next-hop unchanged'. I don't think the problem is on XR2 but XR1. If I shut interface of XR1 to R3 and I let traffic go via R5, everything is fine.  XR2 can't get label from XR1.

    I believe this is between XR2 and R4, yes? When you configure ebgp-multihop for the R4 peer on XR2, does it install a Pop for 10.0.0.4 towards XR1? If so you'll  need to use the ebgp multihop mpls command. This is needed since XR2 is both VPNv4 RR and passing traffic.

     

    I need to try this...I had this same problem that I wrote about before. The way that it was "fixed" was by adding "next-hop unchanged" on XR2's VPNv4 eBGP session to R4. For whatever weird reason IOS-XR does this behavior. Can you please look at my post and see if this is what you are referring to? I would really like to get an answer to this IOS-XR mystery!

    Here is the post:

    http://ieoc.com/forums/t/27055.aspx

     

    Pablo

     

     

  • My config includes 'next-hop unchanged'. I don't think the problem is on XR2 but XR1. If I shut interface of XR1 to R3 and I let traffic go via R5, everything is fine.  XR2 can't get label from XR1.

     

    Are you sure? Double check with show mpls ldp label and show mpls forwarding for the R4 prefix, if its the same thing Im talking about you will see a label coming from XR1 for the prefix via LDP but XR2 will install a Pop action when you configure the ebgp-multihop.

  • My config includes 'next-hop unchanged'. I don't think the problem is on XR2 but XR1. If I shut interface of XR1 to R3 and I let traffic go via R5, everything is fine.  XR2 can't get label from XR1.

     

    Read my post. The problem is not on XR1...XR1 sends the proper label via LDP regardless. XR2 had the label in the LIB, but it does not install it in the LFIB when this command (next-hop unchanged) is not used. This leads me to believe that its strictly an XR1 problem. Also, if you replace XR2 for an IOS router, the problem will not happen...thus again adding to the problem being an IOS-XR issue on XR2.

    Pablo

  • FYI Pablo, TAC have asked me to do a couple of things but nothing concrete yet

  • My config includes 'next-hop unchanged'. I don't think the problem is on XR2 but XR1. If I shut interface of XR1 to R3 and I let traffic go via R5, everything is fine.  XR2 can't get label from XR1.

     

    Read my post. The problem is not on XR1...XR1 sends the proper label via LDP regardless. XR2 had the label in the LIB, but it does not install it in the LFIB when this command (next-hop unchanged) is not used. This leads me to believe that its strictly an XR1 problem. Also, if you replace XR2 for an IOS router, the problem will not happen...thus again adding to the problem being an IOS-XR issue on XR2.

    Pablo

    I read your post just now.  Noticing you didn't get any solution to fix the problem. Isn't it?  My problem is a little diffrenet from yours.  On the 1st day, every thing is working well. I used next-hop-unchanged on both R4 and XR2.  But, after next days, when I tried to setup mdt peering bet. R4 and XR2, I noticed my ldp switching between R4 and XR2 was broken.  My eBGP vpnv4 peering also broken.  At that time, I used labeled unicast ( send-label) for all inter and infra bgp peering. If I checked mpls forwording table, i can see the label but I can't ping and trace.

    Finally, I changed exactly the same like workbook. I redistributed R1,R4 and R3 loopback into ISIS on both R5 and XR1.  I got lebel from R5 but XR1.

    On your problem, you are seeing label of 10.0.0.4 as 'pop' but, in my XR2, I am seeing "unlabelled" even I am using 'next-hop-unchanged' on both routers.

     

  • On your problem, you are seeing label of 10.0.0.4 as 'pop' but, in my XR2, I am seeing "unlabelled" even I am using 'next-hop-unchanged' on both routers.

     

     

    Yes this is then a different issue. Did you end up solving it then by doing the redistribution from BGP into ISIS? 

  • FYI Pablo, TAC have asked me to do a couple of things but nothing concrete yet

    At least they are looking into it, which is much better than before with no Cisco internal support =)

    Thanks again for reaching out to them...much appreciated. 

    -Pablo

     

  • The reason I asked for the configs was I had a similar problem that wrecked my head, but I'm sure I forgot redistribution and that was the problem for me. 

  • OK fill in the blanks time please :)

    I have pasted your configs on to my lab, had to make a few adjustments but it's up and running now.  Re why you didn't have labels I dont know, maybe its just one of those things, maybe it's a bug of some sort, flukey coincidence. Once I put in your config I had labels from R3 for both R1 and R4.  Maybe this is what you were seeing but there was some other issue that I haven't picked up on, if so let me know.

    RP/0/0/CPU0:XR1(config)#do sho mpls for | i 193.3
    Sun Sep 22 20:53:51.443 UTC
    16001  Pop         10.0.193.3/32      Gi0/1/0/0.193 10.0.193.3      726751     
    16008  18          10.0.0.1/32        Gi0/1/0/0.193 10.0.193.3      0          
    16009  Pop         10.0.0.3/32        Gi0/1/0/0.193 10.0.193.3      0          
    16010  17          10.0.0.4/32        Gi0/1/0/0.193 10.0.193.3      98504 

    R3#sho mpl for 10.0.0.1  
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop   
    Label      Label      or Tunnel Id     Switched      interface             
    18         Pop Label  10.0.0.1/32      0             Fa0/0.13   10.0.13.1  
    R3#sho mpl for 10.0.0.4
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop   
    Label      Label      or Tunnel Id     Switched      interface             
    17         Pop Label  10.0.0.4/32      1030033       Fa0/0.34   10.0.34.4

    Next I moved on to BGP and XR1 wasn't advertising XR2 to R3 so my trace was failing. Have you other configs where you get 10.0.0.20/32 in to BGP somehow? I didn't see any ISIS to BGP redistr so I added in a network statement for XR2 (maybe the task says don't do that, again correct me if wrong). Once I did that the BGP peering came up.

    RP/0/0/CPU0:XR1(config)#router bgp 1000
    RP/0/0/CPU0:XR1(config-bgp)# bgp router-id 10.0.0.19
    RP/0/0/CPU0:XR1(config-bgp)# address-family ipv4 unicast
    RP/0/0/CPU0:XR1(config-bgp-af)#net 10.0.0.20/32
    RP/0/0/CPU0:XR1(config-bgp-af)#commit
    Sun Sep 22 21:03:22.687 UTC
    RP/0/0/CPU0:XR1(config-bgp-af)#
    async-r13#2
    [Resuming connection 2 to 12k1 ... ]

    RP/0/3/CPU0:XR2#RP/0/3/CPU0:Sep 22 21:03:46.385 : bgp[1046]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.0.0.4 Up (VRF: default) (AS: 2000)
    ping 10.0.0.4 so 10.0.0.20 cou 100
    Sun Sep 22 21:03:48.452 UTC
    Type escape sequence to abort.
    Sending 100, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    Success rate is 100 percent (100/100), round-trip min/avg/max = 1/1/7 ms
    RP/0/3/CPU0:XR2#

    Next I shut down R3-R5 for pig iron sake (can someone please explain that expression to me!)

    R3(config)#int f0/0.35
    R3(config-subif)#shut
    R3(config-subif)#
    %BGP-5-ADJCHANGE: neighbor 2001:10:0:35::5 Down Interface flap
    %BGP_SESSION-5-ADJCHANGE: neighbor 2001:10:0:35::5 IPv6 Unicast topology base removed from session  Interface flap
    R3(config-subif)#

    With a continuous ping from XR2


    RP/0/3/CPU0:XR2#ping 10.0.0.4 so 10.0.0.20 cou 1000000
    Sun Sep 22 21:09:40.791 UTC
    Type escape sequence to abort.
    Sending 1000000, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
    <snippety snip>
    Success rate is 100 percent (6577/6577), round-trip min/avg/max = 1/1/52 ms

    But I didn't expect anything to drop as the preferred path is via XR1 anyway

    RP/0/3/CPU0:XR2#sho cef 10.0.0.4/32
    Sun Sep 22 21:13:14.122 UTC
    10.0.0.4/32, version 2120, internal 0x4004001 (ptr 0xae3f1e30) [1], 0x0 (0xae3bfed8), 0x450 (0xaeb7f5f0)
     Updated Sep 22 20:50:35.363
     local adjacency 10.19.20.19
     Prefix Len 32, traffic index 0, precedence n/a, priority 4
       via 10.19.20.19, GigabitEthernet0/4/0/2, 7 dependencies, weight 0, class 0 [flags 0x0]
        path-idx 0 [0xaefb95e4 0x0]
        next hop 10.19.20.19
        local adjacency
         local label 16012      labels imposed {16010}

    All of this was done with Gige between the XRs from an earlier experiement so I need to put the POS link back in, 1st this though, alter the metric over the Gige to force traffic via R5

    RP/0/3/CPU0:XR2(config)#router isis 1
    RP/0/3/CPU0:XR2(config-isis)#int g0/4/0/2
    RP/0/3/CPU0:XR2(config-isis-if)#add ipv4
    RP/0/3/CPU0:XR2(config-isis-if-af)#metric 10000
    RP/0/3/CPU0:XR2(config-isis-if-af)#commit
    Sun Sep 22 21:15:28.086 UTC
    RP/0/3/CPU0:Sep 22 21:15:28.211 : isis[1003]: %ROUTING-ISIS-4-WD_METRIC_NOT_CONF : In the topology IPv4 Unicast GigabitEthernet0/4/0/2 has a wide metric of 10000 but level L2 is configured to generate narrow metrics.  Maximum narrow value 63 is used instead
    RP/0/3/CPU0:Sep 22 21:15:29.472 : config[65740]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'admin'. Use 'show configuration commit changes 1000000785' to view the changes.
    RP/0/3/CPU0:XR2(config-isis-if-af)#do sho cef 10.0.0.4/32
    Sun Sep 22 21:15:49.041 UTC
    10.0.0.4/32, version 2123, internal 0x4004001 (ptr 0xae3f1e30) [1], 0x0 (0xae3bfed8), 0x450 (0xaeb7f460)
     Updated Sep 22 21:15:30.271
     local adjacency 10.0.205.5
     Prefix Len 32, traffic index 0, precedence n/a, priority 1
       via 10.0.205.5, GigabitEthernet0/4/0/0.205, 5 dependencies, weight 0, class 0 [flags 0x0]
        path-idx 0 [0xaefb9174 0x0]
        next hop 10.0.205.5
        local adjacency
         local label 16012      labels imposed {25}

    Again when I fail R3-R5 there is no problem where R5 then XR1 are the path egress to AS2000, BGP remains up.

    RP/0/3/CPU0:XR2(config-isis-if-af)#do trace 10.0.0.4 so 10.0.0.20
    Sun Sep 22 21:16:39.140 UTC

    Type escape sequence to abort.
    Tracing the route to 10.0.0.4

     1  10.0.205.5 [MPLS: Label 25 Exp 0] 8 msec  3 msec  2 msec
     2  10.0.195.19 [MPLS: Label 16010 Exp 0] 4 msec  3 msec  3 msec
     3  10.0.193.3 [MPLS: Label 17 Exp 0] 1 msec  2 msec  2 msec
     4  10.0.34.4 2 msec  *  1 msec
    RP/0/3/CPU0:XR2(config-isis-if-af)#do sho bgp vpnv4 uni summ | i 0.4
    Sun Sep 22 21:17:48.096 UTC
    10.0.0.4          0  2000    4706    4302      210    0    0 00:14:02         10

    So now the link is back over the POS interface, I removed the metric 10000, outsmarted by your  narrow metrics :)

    RP/0/3/CPU0:XR2(config-isis-if-af)#do sho mpls for prefi 10.0.0.4/32
    Sun Sep 22 21:26:15.629 UTC
    Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes      
    Label  Label       or ID              Interface                    Switched   
    ------ ----------- ------------------ ------------ --------------- ------------
    16012  16010       10.0.0.4/32        PO0/7/0/0.1920 10.19.20.19     0          
    RP/0/3/CPU0:XR2(config-isis-if-af)#
    RP/0/3/CPU0:XR2(config-isis-if-af)#do trace 10.0.0.4 so 10.0.0.20
    Sun Sep 22 21:26:27.238 UTC

    Type escape sequence to abort.
    Tracing the route to 10.0.0.4

     1  10.19.20.19 [MPLS: Label 16010 Exp 0] 92 msec  5 msec  3 msec
     2  10.0.193.3 [MPLS: Label 17 Exp 0] 3 msec  1 msec  1 msec
     3  10.0.34.4 2 msec  *  1 msec
    RP/0/3/CPU0:XR2(config-isis-if-af)#

    So the link works and we dont see to have the issue Pablo did right at this moment, do we, I'm tired so not really paying attention?

    Now to make the traffic go via R5 again with its eBGP peering down.

    RP/0/3/CPU0:XR2(config-isis-if-af)#metr 63
    RP/0/3/CPU0:XR2(config-isis-if-af)#commit
    Sun Sep 22 21:28:16.746 UTC
    RP/0/3/CPU0:Sep 22 21:28:18.137 : config[65740]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'admin'. Use 'show configuration commit changes 1000000789' to view the changes.
    RP/0/3/CPU0:XR2(config-isis-if-af)#do trace 10.0.0.4 so 10.0.0.20
    Sun Sep 22 21:28:22.278 UTC

    Type escape sequence to abort.
    Tracing the route to 10.0.0.4

     1  10.0.205.5 [MPLS: Label 25 Exp 0] 4 msec  2 msec  3 msec
     2  10.0.195.19 [MPLS: Label 16010 Exp 0] 5 msec  3 msec  3 msec
     3  10.0.193.3 [MPLS: Label 17 Exp 0] 1 msec  2 msec  2 msec
     4  10.0.34.4 2 msec  *  1 msec
    RP/0/3/CPU0:XR2(config-isis-if-af)#
    RP/0/3/CPU0:XR2(config-isis-if-af)#do sho bgp vpnv4 uni summ | i 0.4
    Sun Sep 22 21:28:34.880 UTC
    10.0.0.4          0  2000    4717    4313      210    0    0 00:24:49         10

    Does that cover it off? Was it just XR2 wasnt being advertised in to AS2000? Is there a word limit on posts? I hope not!

  • Next I moved on to BGP and XR1 wasn't advertising XR2 to R3 so my trace was failing. Have you other configs where you get 10.0.0.20/32 in to BGP somehow? I didn't see any ISIS to BGP redistr so I added in a network statement for XR2 (maybe the task says don't do that, again correct me if wrong). Once I did that the BGP peering came up.

    Again when I fail R3-R5 there is no problem where R5 then XR1 are the path egress to AS2000, BGP remains up.

    Does that cover it off? Was it just XR2 wasnt being advertised in to AS2000? Is there a word limit on posts? I hope not!

    Your result is perfect while I am facing problem.  In my result, XR2 didn't get R4 label via XR1.  XR2's loopback was annouced by network statement of XR2's ipv4 session.  R4 get XR2's loopback, I can see.

    Let me try again tonight.  As I am redistributing, BGP into ISIS, all the way routers have all routes.  So, I can communicate but not label switching.

  • Yes this is then a different issue. Did you end up solving it then by doing the redistribution from BGP into ISIS? 

    Nope, i faced this problem after I redistributed from BGP into ISIS.  Before that, I used BGP to deliver label. I get label but I can't trace to R4.  [:(]

  • Have you tried ebgp-multihop mpls as I suggested?

  • Have you tried ebgp-multihop mpls as I suggested?

    Not yet.  I will do remote lab tonight and will try. By the way, following is the right configuration?

    RP/0/RSP0/CPU0:XR2(config-bgp)#nei 10.0.0.4
    RP/0/RSP0/CPU0:XR2(config-bgp-nbr)#ebgp-multihop ?
      <1-255>  maximum hop count
      mpls     Disable BGP MPLS forwarding
      <cr>    
    RP/0/RSP0/CPU0:XR2(config-bgp-nbr)#ebgp-multihop mpls

     

     

     

  • Have you tried ebgp-multihop mpls as I suggested?

    Not yet.  I will do remote lab tonight and will try. By the way, following is the right configuration?

    RP/0/RSP0/CPU0:XR2(config-bgp)#nei 10.0.0.4
    RP/0/RSP0/CPU0:XR2(config-bgp-nbr)#ebgp-multihop ?
      <1-255>  maximum hop count
      mpls     Disable BGP MPLS forwarding
      <cr>    
    RP/0/RSP0/CPU0:XR2(config-bgp-nbr)#ebgp-multihop mpls

    Yeah exactly. That will prevent implicit-null rewrites done by XR in some scenarios.

     

  • I will try this out today. The more important question would be why does this happen? Is this implicit-null rewrite something that is supposed to happen? If so, what is the reason behind it? 

    10.0.0.4/32 is an ISIS route, and the label learned is via LDP. 

     

    "Use of the mpls option in the ebgp-multihop command prevents BGP from enabling MPLS on the peering interface and also prevents allocation of Implicit-NULL rewrite labels for nexthop addresses learned from the peer. This is useful in some scenarios in which MPLS forwarding labels to the nexthops have already been learned via BGP labeled-unicast or LDP."

     

    I just cant make any sense of this "implicit-null rewrite" thing. It breaks things!!

    Pablo

     

  • One day, one problem.  I wonder why it is happening. [;)]

     

    XR2

    16008  16011      
    10.0.0.3/32                    
    10.0.0.19       0          

    16009  26         
    10.0.0.1/32                    
    10.0.0.5        0          

    16010  Pop        
    10.0.0.4/32        PO0/7/0/0.1920
    10.19.20.19     2299       

     

    B    10.0.0.1/32 [200/0] via 10.0.0.5, 00:02:29

    i L1
    10.0.0.2/32 [115/10] via 10.0.220.2, 01:21:00, GigabitEthernet0/4/0/0.220

    B    10.0.0.3/32 [200/0] via 10.0.0.19, 00:04:23

    B    10.0.0.4/32 [200/0] via 10.0.0.19, 00:04:23

     

    Now,I am getting Label POP for 10.0.0.4 via XR1. next-hop is interface ip instead of loopback. I am sure, I have configure 'next-hop-unchanged' under nei 10.0.0.4

  • Just tested "ebgp multihop mpls"

    This totally works! 

     

    RP/0/3/CPU0:XR2#show run router bgp 1000 neighbor 10.0.0.4       

    Mon Sep 23 08:00:34.092 UTC

    router bgp 1000

     neighbor 10.0.0.4

      remote-as 2000

      ebgp-multihop 255 mpls

      update-source Loopback0

      address-family vpnv4 unicast

       route-policy PASS in

       route-policy PASS out

      !

      address-family vpnv6 unicast

       route-policy PASS in

       route-policy PASS out

       next-hop-unchanged

     

     

    RP/0/3/CPU0:XR2#show mpls forwarding prefix 10.0.0.4/32   

    Mon Sep 23 08:01:12.056 UTC

    Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes       

    Label  Label       or ID              Interface                    Switched    

    ------ ----------- ------------------ ------------ --------------- ------------

    16004  16001       10.0.0.4/32        PO0/7/0/0.1920 10.19.20.19     5976    

     

     

     

    Now the "extra hop" through R4 that  happens when the "next-hop unchanged" command is not used is seen: 

     

    R8#traceroute 172.16.0.6

     

    Type escape sequence to abort.

    Tracing the route to 172.16.0.6

     

      1 172.16.208.20 [MPLS: Label 16017 Exp 0] 4 msec 4 msec 0 msec

      2 10.19.20.19 [MPLS: Labels 16001/42 Exp 0] 8 msec 0 msec 4 msec

      3 10.0.193.3 [MPLS: Labels 18/42 Exp 0] 4 msec 0 msec 4 msec

      4 10.0.34.4 [MPLS: Label 42 Exp 0] 0 msec 0 msec 4 msec

      5 172.16.16.1 [AS 2000] [MPLS: Label 26 Exp 0] 0 msec 4 msec 0 msec

      6 172.16.16.6 [AS 2000] 4 msec *  0 msec

     

     

     

    Does anyone know why this implicit-null re-write happens? And under what conditions does it happen? This is the first time that I ever run into it...

     

    Pablo

  • Just tested "ebgp multihop mpls"

    This totally works! 

    Pablo

    I tested it but result is the same.  [:(]

  • Probably different problems then. The implicit null rewrite is only a problem when the RR is also in the traffic path, that's why this isnt an issue in the earlier labs.

  • Just tested "ebgp multihop mpls"

    This totally works! 

    Pablo

    I tested it but result is the same.  Sad

    I changed encapsulation type from FR to PPP, I can communicate remote routers.  But, label is still POP for R4.

    16008  16011      
    10.0.0.3/32                    
    10.0.0.19       14672      

    16009  16012      
    10.0.0.1/32                    
    10.0.0.19       9117       

    16010  Pop        
    10.0.0.4/32        PO0/7/0/0    10.19.20.19     258        

    After I set 'ebgp mulitihop mpls' under nei 10.0.0.4, I can get label and mpls switching to R4.  But, mpls forwarding table is showing NO ID instead of R4 Router-id.

     

    16008  16011      
    10.0.0.3/32                    
    10.0.0.19       0          

    16009  16012      
    10.0.0.1/32                    
    10.0.0.19       2191       

    16010  16013      
    No ID                          
    10.0.0.19       107        

     

    But, after I changed back to Frame-relay, nothing work even I set 'ebgp multihop mpls'.

     

    That is fine. I give up. If someone like to test my problem, I will provide you my configuration.  Please give my upload location/access such as e-mail address or FTP or something else.

     

    Thank you all advising me for this problem.

  • Probably different problems then. The implicit null rewrite is only a problem when the RR is also in the traffic path, that's why this isnt an issue in the earlier labs.

    Could you please point me in the right direction as to why or when this imp-null rewrite issue happens? I cant seem to get the concept behind the procedure since on this case it breaks the data path. 

    Thanks in advance,

    Pablo

     

Sign In or Register to comment.