task 4.3 volume II lab 12

i had the idea for this task to activate mpls only on the serial link between R5 and R4. That was interesting because at the end of the task although i was able to see the loopback of VPNA in SW4 i wasn`t able to ping it.After 30 minutes passed reviewing my config i thought if the problem could be because of the returning traffic from R4 going through a non MPLS path via fastethernet0/0 interface. After changing the bandwidth over that segment i forced the path going to the serial link and everything worked as expected. But that sound new to me cause i always saw that MPLS is not mandatory to be configured for exchange of VRFs via bgp but only after forcing the path via MPLS i got the connection. Am i wrong in my assumption or am i missing something else in the task?

Comments

  • JoeMJoeM ✭✭✭

    Hi Pgallo,

    I think that I understand what you are saying. 

    What I have normally seen with VPNv4, are full exchanges of routes without MPLS.  But I cannot ping/connect without MPLS.  

         1. see routes exchanged (with/without MPLS).

         2. connect (needs MPLS)

    It sounds like you achieved the second part of this, by forcing the path over the serial.

    Were you still able to see the prefixes, even when you were not able to connect?

  • Yes Joe i was able to see the prefixes when i wasn't able to reach them via ping, but i got connection only when the path flowed through MPLS cloud. It looks like MPLS was required to achieve full connection but i'm sure i did labs before where the MPLS part was not implemented and i got connection anyway through BGP VRFs...so i'm going to find those labs to be able to see the differences

  • JoeMJoeM ✭✭✭

    I also recall something like this in a troubleshooting lab that I did recently.  I do not recall which one, so I am reluctant to talk about any exeptions to the rule. I do remember adding MPLS myself (out of reflex), but the SG did not show this as part of the fix.  I want to think that the Route-Targets for VRFs were exactly the same, and the BGP routers were directly connecting.  I should have made a note on it, as I did plan to go back and review it again (I was racing time in the lab). 

    EDIT:  maybe the directly connected BGP routers (in VPNv4) do not need MPLS?  Because they would pop the labels anyway?  Later today, I am going to lab this up, and experiment with it. So far, I have not found any documenation supporting the idea.

     

    With that said, this lab task has an important situation.   We are connecting VRF's between R5 and R6 (VPNv4), and the route-target labels need to transit through the R4 BGP router. For sure, MPLS is necessary for successful connectivity.  No doubts on this one.

    Here is a note from INE's WB-1 MPLS (14.4 MP-BGP VPNv4)

    address family named “VPNv4” (VPN IPv4) has been added to BGP along with a new NLRI format. Every VPNv4 prefix has the RD associated with it and the corresponding MPLS label, in addition to the normal BGP attributes.

  • EDIT:  maybe the directly connected BGP routers (in VPNv4) do not need MPLS?  Because they would pop the labels anyway?  Later today, I am going to lab this up, and experiment with it. So far, I have not found any documenation supporting the idea.

    Yes could agree from a theory perspective but i found examples that actually look in contraddition, like in LAB 11, where a tunnel is used to allow a directly BGP adjacency but MPLS is not used and in Lab 6 where R5 and R4 are peering on the same subnet and they use MPLS.

    I will lab it again too to check any useful infos

    Edited: By the way what i believe happened in the task is that without enabling MPLS the PE router would not be able to see which VPN label to use to identify the correct VRF / cef entry to route the packet to, also, another possible cause i thought is that the path switching technology should be consistent across the network. With a forwarding path thorugh MPLS and a returning path over a non MPLS segment traffic would probably end up in being dropped. But once again those are just suppositions.

     

  • JoeMJoeM ✭✭✭

    [8-|]

    Woo Hoooo  Worth the time spent.  Yes, it worked for directly connected BGP neighbors.  

    MPLS seems to be automatically take care of by BGP VPNv4.

     

    Here is a quick dump of some output.   Can provide more info if you need it.

     

                             SIMPLE SETUP: 

    Client_A (RIP)<-->VPNA  R1(PE1) <---VPNv4---> (PE2) R2  VPNB<-->(OSPF)Client_B

    R1# ip vrf VPNA
                rd 100:11
                route-target export 100:111
                route-target import 100:222

    R2# ip vrf VPNB
               rd 100:22
               route-target export 100:222
               route-target import 100:111

    ==========CLIENT_A OUTPUT=========

                Target address is 144.144.144.144


    CLIENT_VRFA#sh ip route rip
         22.0.0.0/24 is subnetted, 1 subnets
    R       22.22.22.0 [120/5] via 11.11.11.1, 00:00:06, FastEthernet0/1
         144.144.0.0/32 is subnetted, 1 subnets
    R       144.144.144.144 [120/5] via 11.11.11.1, 00:00:06, FastEthernet0/1




    CLIENT_VRFA#traceroute 144.144.144.144 source lo0




    Tracing the route to 144.144.144.144
      1 11.11.11.1 40 msec 32 msec 20 msec <--R1(PE1)
      2 22.22.22.2 [MPLS: Label 19 Exp 0] 48 msec 36 msec 40 msec<--R2(PE2)
      3 22.22.22.4 52 msec 64 msec 80 msec  <---Client B

    =========PE1 (R1)  OUTPUT=========

         labels and mpls interface installed automatically

    R1#sh mpls inter
    Interface              IP            Tunnel   Operational
    FastEthernet0/0        No            No       Yes
    R1#
    R1#sh mpls ldp neigh

    R1#
    R1#sh run | in mpls
    R1#
    R1#
    R1#sh mpls forwarding-table
    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
    tag    tag or VC   or Tunnel Id      switched   interface
    16     Untagged    150.1.2.0/24      0          Fa0/0      1.1.1.2 <--FROM R2
    17     Pop tag     1.1.1.2/32        0          Fa0/0      1.1.1.2 <--R2 BGP
    18     Untagged    3.3.3.0/24[V]     570        Fa0/1      11.11.11.3 <---VRF Client_A Lo0
    19     Aggregate   11.11.11.0/24[V]  1112 <---local vrf interface facing client
    20     Untagged    33.33.33.0/24[V]  696        Fa0/1      11.11.11.3 <---Clien_A Lo100

  • Joe so MPLS is totally disabled. Does LFIB table is populated only by VPN labels locally originated at PE side?

    R1#sh mpls forwarding-table
    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
    tag    tag or VC   or Tunnel Id      switched   interface
    16     Untagged    150.1.2.0/24      0          Fa0/0      1.1.1.2 <--FROM R2
    17     Pop tag     1.1.1.2/32        0          Fa0/0      1.1.1.2 <--R2 BGP
    18     Untagged    3.3.3.0/24[V]     570        Fa0/1      11.11.11.3 <---VRF Client_A Lo0
    19     Aggregate   11.11.11.0/24[V]  1112 <---local vrf interface facing client
    20     Untagged    33.33.33.0/24[V]  696        Fa0/1      11.11.11.3 <---Clien_A Lo100

    please what is the output of: "sh ip cef vrf VPNA 144.144.144.144" and "sh run | s router bgp" ? 

    thank you

  • JoeMJoeM ✭✭✭

    I sent you a link the Dynamip topology and configs.   check your email.

     

    MPLS is not disabled. By default MPLS is enabled, but nothing applied to interfaces.

    Here is the output you asked for.

     

    R1--PE1#sh ip cef vrf VPNA 144.144.144.144
    144.144.144.144/32, version 9, epoch 0, cached adjacency 1.1.1.2
    0 packets, 0 bytes
      tag information set
        local tag: VPN-route-head
        fast tag rewrite with Fa0/0, 1.1.1.2, tags imposed: {19}
      via 1.1.1.2, 0 dependencies, recursive
        next hop 1.1.1.2, FastEthernet0/0 via 1.1.1.2/32
        valid cached adjacency
        tag rewrite with Fa0/0, 1.1.1.2, tags imposed: {19}

     

    R1--PE1#sh run | s router bgp|router rip


    router rip
     version 2
     no auto-summary
     !
     address-family ipv4 vrf VPNA
      redistribute bgp 100 metric 5
      network 11.0.0.0
      no auto-summary
      version 2
     exit-address-family


    router bgp 100
     no synchronization
     bgp log-neighbor-changes
     neighbor 1.1.1.2 remote-as 200
     no auto-summary
     !
     address-family vpnv4
      neighbor 1.1.1.2 activate
      neighbor 1.1.1.2 send-community both
     exit-address-family
     !
     address-family ipv4 vrf VPNA
      redistribute rip metric 5
      no synchronization
     exit-address-family

     

    image

  • JoeMJoeM ✭✭✭

    R1--PE1#sh bgp vpnv4 unicast all
    BGP table version is 9, local router ID is 150.1.1.1
    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
    Route Distinguisher: 100:11 (default for vrf VPNA)
    *> 11.11.11.0/24    0.0.0.0                  0         32768 ?
    *> 22.22.22.0/24    1.1.1.2                  0             0 200 ?
    *> 33.33.33.0/24    11.11.11.3               5         32768 ?
    *> 144.144.144.144/32
                                  1.1.1.2                 11             0 200 ?
    Route Distinguisher: 100:22
    *> 22.22.22.0/24     1.1.1.2                  0             0 200 ?
    *> 144.144.144.144/32
                                  1.1.1.2                 11             0 200 ?

  • Nice job Joe,

    i love those brainstorms , they are helpful to isolate some cloudy issue like this one :)

  • JoeMJoeM ✭✭✭

    Glad you liked it.   I was surprised to see the output. Good learning (and not a dead-end experiment).

     

    So now, my theory expands like this.

    I am betting that the only place that MPLS is mandatory (manually implemented), is on the interfaces of TRANSIT BGP routers in a VPNv4 path. 

     

    I am not saying that I would do it like that in the exam, but I am curious.  It definitely makes troubleshooting VPNv4 a little clearer.

    I will work on this later (adding a transit router or two).  Feel free to manipulate the lab further and give any ideas/suggestions (I sent you a link to the topology/configs).

    Cheers!

Sign In or Register to comment.