[2_alex]

 

Между парами CE-A(A7) и R1, CE-B(B8) и R3 поднят ospf, между R1 и R3 MP-BGP

 

В лабе предлагается поднять shamlink между R1 и R3 в vrf vpn-a, чтобы CE-A и CE-B видел маршруты друг друга "напрямую", т.е. с preference OSPF/10

 

Но ведь даже, если не конфигурить shamlink, то они и так видят друг друга с preference OSPF/10, а не OSPF/150 за счёт передачи rte-type community через MP-BGP(при редистрибьюции из ospf в mp-bgp)

 

Собственно вот вывод таблицы маршрутов без shamlink с CE-B:

# run show route logical-system B8    

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.10.0/24       *[OSPF/150] 00:22:36, metric 0, tag 3489726440
                   > to 10.0.11.1 via lt-1/2/0.83
10.0.11.0/24       *[Direct/0] 1d 01:50:30
                   > via lt-1/2/0.83
10.0.11.2/32       *[Local/0] 1d 01:50:30
                     Local via lt-1/2/0.83
!!!!192.168.11.1/32    *[OSPF/10] 00:22:36, metric 2
                   > to 10.0.11.1 via lt-1/2/0.83
192.168.11.2/32    *[Direct/0] 1d 01:51:58
                   > via lo0.8
224.0.0.5/32       *[OSPF/10] 00:28:06, metric 1
                     MultiRecv

 

!!!! - помечен маршрут от CE-A

 

# run show ospf database logical-system B8              
   OSPF database, Area 0.0.0.0
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   10.0.11.1        10.0.11.1        0x80000004  1308  0x22 0x6ee0  48
Router  *192.168.11.2     192.168.11.2     0x80000004  1307  0x22 0xe485  60
!!!!Summary  192.168.11.1     10.0.11.1        0x80000001  1436  0xa2 0x2907  28
   OSPF AS SCOPE link state database
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Extern   10.0.10.0        10.0.11.1        0x80000002   213  0xa2 0x75d7  36

 

Т.е. префикс 192.168.11.1 распространяется с помощью LSA type 3 и поэтому имеет preference 10. Какой смысл тогда поднимать shamlink? Ну будет он распространяться как LSA type 1, preference-то от этого не изменится, метрика тоже. Зачем оно тогда нужно?

 

По поводу rte-type community см. ниже:

# run show route table bgp.l3vpn 192.168.11.1/32 extensive logical-system R3

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
192.168.1.1:1:192.168.11.1/32 (1 entry, 0 announced)
       *BGP    Preference: 170/-101
               Route Distinguisher: 192.168.1.1:1
               Next hop type: Indirect
               Address: 0x9260688
               Next-hop reference count: 6
               Source: 192.168.1.1
               Next hop type: Router, Next hop index: 1782
               Next hop: 172.22.212.2 via lt-1/2/0.32 weight 0x1, selected
               Label-switched-path to-R1
               Label operation: Push 299920, Push 299776(top)
               Label TTL action: prop-ttl, prop-ttl(top)
               Protocol next hop: 192.168.1.1
               Push 299920
               Indirect next hop: 90d03a0 1048772
               State: <Active Int Ext>
               Local AS: 65512 Peer AS: 65512
               Age: 38:46 	Metric: 1 	Metric2: 2 
               Task: BGP_65512.192.168.1.1+179
               AS path: I
!!!!!                Communities: target:65512:101 rte-type:0.0.0.0:1:0
               Import Accepted
               VPN Label: 299920
               Localpref: 100
               Router ID: 192.168.1.1
               Secondary Tables: vpn-a.inet.0
               Indirect next hops: 1
                       Protocol next hop: 192.168.1.1 Metric: 2
                       Push 299920
                       Indirect next hop: 90d03a0 1048772
                       Indirect path forwarding next hops: 1
                               Next hop type: Router
                               Next hop: 172.22.212.2 via lt-1/2/0.32 weight 0x1
		192.168.1.1/32 Originating RIB: inet.3
		  Metric: 2			  Node path count: 1
		  Forwarding nexthops: 1
			Nexthop: 172.22.212.2 via lt-1/2/0.32

 

Конфиг R3 и CE-B ниже. R1 и CE-A аналогичны.

# show logical-systems R3 
interfaces {
   lt-1/2/0 {
       unit 32 {
           encapsulation ethernet;
           peer-unit 23;
           family inet {
               address 172.22.212.1/24;
           }
           family mpls;
       }
       unit 38 {
           encapsulation ethernet;
           peer-unit 83;
           family inet {
               address 10.0.11.1/24;
           }
       }
   }
   lo0 {
       unit 3 {
           family inet {
               address 192.168.1.3/32;
           }
       }
   }
}
protocols {
   rsvp {
       interface lt-1/2/0.32;
   }                                   
   mpls {
       icmp-tunneling;
       no-cspf;
       label-switched-path to-R1 {
           to 192.168.1.1;
       }
       interface lt-1/2/0.32;
   }
   bgp {
       group int {
           type internal;
           local-address 192.168.1.3;
           family inet {
               unicast;
           }
           family inet-vpn {
               unicast;
           }
           export nh-self;
           remove-private;
           neighbor 192.168.1.1;
       }
   }
   ospf {
       area 0.0.0.0 {
           interface lo0.3 {
               passive;
           }
           interface lt-1/2/0.32 {     
               interface-type p2p;
           }
       }
   }
}
policy-options {
   policy-statement nh-self {
       then {
           next-hop self;
       }
   }
   policy-statement vpn-a-bgp-to-ospf {
       from protocol bgp;
       then accept;
   }
}
routing-instances {
   vpn-a {
       instance-type vrf;
       interface lt-1/2/0.38;
       route-distinguisher 192.168.1.2:1;
       vrf-target target:65512:101;
       protocols {
           ospf {
               export vpn-a-bgp-to-ospf;
               area 0.0.0.0 {
                   interface lt-1/2/0.38 {
                       interface-type p2p;
                   }
               }
           }
       }
   }
}
routing-options {
   autonomous-system 65512;
}

 

# show logical-systems B8    
interfaces {
   lt-1/2/0 {
       unit 83 {
           encapsulation ethernet;
           peer-unit 38;
           family inet {
               address 10.0.11.2/24;
           }
       }
   }
   lo0 {
       unit 8 {
           family inet {
               address 192.168.11.2/32;
           }
       }
   }
}
protocols {
   ospf {
       area 0.0.0.0 {
           interface lt-1/2/0.83 {
               interface-type p2p;
           }
           interface lo0.8 {
               passive;
           }
       }
   }
}
policy-options {
   policy-statement exp-lo {
       from {
           route-filter 192.168.11.2/32 exact accept;
       }
   }
}
routing-options {
   autonomous-system 65101 loops 2;
}

[nnm]

Т.е. префикс 192.168.11.1 распространяется с помощью LSA type 3 и поэтому имеет preference 10. Какой смысл тогда поднимать shamlink? Ну будет он распространяться как LSA type 1, preference-то от этого не изменится, метрика тоже. Зачем оно тогда нужно?

Единственный сценарий, при котором shamlink нужен это если между CE-A и CE-B есть прямой резервный канал с малой емкостью, на котором поднят OSPF. Без shamlink-а получится так, что трафик пойдет в этот резервный канал потому, что через него маршруты будут приходить в LSA type 1, что предпочтительнее, чем LSA type 3, который приходит через MPLS. Shamlink позволит получить type 1 из MPLS и путь трафика будет определяться метрикой, которую уже можно крутить.

В приведенной Вами топологии shamlink не нужен.

[artmc]

Shamlink нужен в случае если между се у вас есть независимый канал, который в ospf будет intra area и будет выбираться всегда как лучший.

[applx]

что то вы здесь много вопросов по Джуну задаете вместо того чтоб просто гуглом воспользоватся, тем более что на сайте Джуна все на шару с обьяснением. Это вы так к JNCIE готовитесь? :)