4

Consider the following output:

router#show ip bgp vpnv4 rd 300:1  5.5.5.5/26
BGP routing table entry for 300:1:5.5.5.5/26, version 538213
Paths: (2 available, best #2, no table)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  Local, (Received from a RR-client)
    8.20.2.1 (metric 30) from 8.20.2.1 (8.20.2.1)
      Origin incomplete, metric 5222400, localpref 100, valid, internal
      Extended Community: SoO:80:13 RT:300:1
        Cost:pre-bestpath:129:5222400 (default-2142261247) 0x8800:0:0
        0x8801:80:258560 0x8802:65281:25600 0x8803:1:1500 0x8804:0:60293292
        0x8805:3:0
      Connector Attribute: count=1
       type 1 len 12 value 300:1:8.20.2.1
      mpls labels in/out nolabel/24059
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  Local, (Received from a RR-client)
    8.20.2.2 (metric 30) from 8.20.2.2 (8.20.2.2)
      Origin incomplete, metric 107520, localpref 100, valid, internal, best
      Extended Community: SoO:80:13 RT:300:1 Cost:pre-bestpath:129:107520
        0x8800:0:0 0x8801:80:2816 0x8802:65281:25600 0x8803:1:1500
        0x8804:0:60293292 0x8805:3:0
      Connector Attribute: count=1
       type 1 len 12 value 300:1:8.20.2.2
      mpls labels in/out nolabel/24056
      rx pathid: 0, tx pathid: 0x0

I'm redistributing from EIGRP to iBGP here and by putting delay on a specific interface within the LAN, I've changed the metric value for 3.20.2.1 to metric 5222400 The path for 8.20.2.2 is then set as best since it has a smaller metric of metric 107520

How exactly is the metric there calculated? I'm assuming its part of some eigrp to bgp delay formula but I cannot find any specific information to how it relates on Cisco's documentation so far.

Thanks!

5

Since Cisco controls the EIGRP spec, they automatically provide additional information to BGP when EIGRP is advertised/redistributed into an MPLS VPN.

This excerpt from Cisco's MPLS VPN support for EIGRP page gives the following details (emphasis mine):

EIGRP Connectivity Between VPN Client Sites over a Service Provider Backbone

In Figure 1, the EIGRP routes in Site 1 are carried through the BGP core network as iBGP routes. The EIGRP routes in "Site 1" and "Site 2" are converted to iBGP routes and EIGRP extended community attributes are appended to the iBGP routes. (See Table 1 for a description of these attributes.) The EIGRP extended community attributes are appended to the EIGRP routes when they are redistributed into BGP as iBGP routes, and VPN routing information is redistributed between the PE routers by multiprotocol BGP.

The routes that originate in "Site 1" travel to the PE router that is connected to the CE router in "Site 2" of the VPN and are then converted back to EIGRP routes using the EIGRP extended community attributes. EIGRP routes are treated the same in "Site 1" and "Site 2." If the route is internal in "Site 1", it will be internal in "Site 2", and if the route is external in "Site 1", it will be external in "Site 2." All EIGRP metrics are preserved, and EIGRP metric information, along with the autonomous system, tag, and external data, is carried across the VPN over the BGP core network.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.