如何在SDN GW上汇总虚拟机路由



  • 在Tungsten Fabric中,每个虚拟网络都不过是vRouter上的一个VRF。这使得vRouter在经典的L3VPN场景中看起来像是一个PE节点。

    每个虚拟网络都被分配了一个CIDR,例如10.10.10.0/24。vRouter有一个/32的路由指向连接到虚拟网络的每个虚拟机。

    通过在虚拟网络上配置一个route-target,这些路由可以被通告到SDN GW。

    这是一个PE-PE交互。那么这意味着什么?

    SDN GW将接收这些路由,并将其存储在bgp.l3vpn.0表中。如果SDN GW有另一个MP-BGP会话,例如朝向骨干(backbone)路由反射器,那么这些路由将被发送到RR,并有可能到达网络中的任何其它远程PE。

    由于通常Tungsten Fabric和SDN GW位于不同的自治系统中,我们处理的是一个经典的Inter-AS option B方案:来自TF的路由会按原样发送到骨干网。

    这样很好,为了将目的地为虚拟机的流量发送到虚拟机运行的确切计算节点,需要拥有/32的路由。想象一下,只有一个/24的网络指向一个随机的计算节点的情况。端到端流量无论如何都会工作,但平均而言,由于虚拟机可能不在通用/24路由指向的计算节点上运行,需要额外的流量跳数。这将产生不必要的东西向流量。在SDN GW上拥有/32路由可以避免这种情况。

    如果我们进一步将这些路由导出到远程PE,那么远程PE也知道正确的目的地来发送数据包。这一切都很好对吗?是,也不是。

    想象一下,一个大规模的TF集群,有许多虚拟机和许多虚拟网络“暴露”在SDN GW上。这将意味着大量的/32在骨干网上旅行。这是可扩展的吗?也许不能!

    另外,所有属于集群上配置的虚拟网络的虚拟机都位于同一个SDN GW的背后,所以拥有所有这些/32路由可能会被视为冗余信息:重要的是到达SDN GW,而SDN GW是唯一需要知道/32细节的。

    其实,这并不完全正确。假设我们的VN有CIDR 10.10.10.0/24。远程PE将向SDN GW发送属于10.10.10.0/24的任何IP的流量,即使不存在具有该特定IP的虚拟机……所以,是的,有一些缺点,但还是可以接受的。

    那么应该如何实现呢?需要SDN GW知道/32,但只通告相应的网络方面(例如/24)的路由。

    0f365f4c-a014-4811-8020-a70a3f177f18-image.png

    这可以通过在SDN GW上配置一个VRF来实现。

    该VRF将从Tungsten Fabric导入路由,匹配正确的路由目标。

    set routing-instances s1 instance-type vrf
    set routing-instances s1 route-distinguisher 2.2.2.100:1
    set routing-instances s1 vrf-import s1-imp
    set routing-instances s1 vrf-export s1-exp
    set policy-options policy-statement s1-imp term contrail from protocol bgp
    set policy-options policy-statement s1-imp term contrail from community s1-vn
    set policy-options policy-statement s1-imp term contrail then accept
    set policy-options community s1-vn members target:64520:100
    

    这将导致/32路由被导入到VRF路由表中。

    root@esto# run show route table s1.inet.0 10.10.10/24
     
    s1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
     
    10.10.10.10/32     *[BGP/170] 00:47:58, localpref 100, from 1.1.1.100
                          AS path: 64520 64500 I, validation-state: unverified
                        > via gr-0/0/10.0, Push 299856
    10.10.10.11/32     *[BGP/170] 00:47:58, localpref 100, from 1.1.1.100
                          AS path: 64520 64500 I, validation-state: unverified
                        > via gr-0/0/10.0, Push 299856
    10.10.10.12/32     *[BGP/170] 00:47:58, localpref 100, from 1.1.1.100
                          AS path: 64520 64500 I, validation-state: unverified
                        > via gr-0/0/10.0, Push 299856
    

    下一跳是MPLSoGRE隧道,朝向Tungsten Fabric方向。

    现在,我们在VRF上配置一个聚合路由:

    set routing-instances s1 routing-options aggregate route 10.10.10.0/24 discard
    

    最后,需要将该聚合路由朝向路由反射器发布通告。这是通过vrf-export策略完成的:

    set policy-options policy-statement s1-exp term agg from protocol aggregate
    set policy-options policy-statement s1-exp term agg then community add s1-vn
    set policy-options policy-statement s1-exp term agg then accept
    set policy-options policy-statement s1-exp then reject
    

    因此,我们现在向骨干网通告的是聚合路由:

    root@esto# run show route advertising-protocol bgp 3.3.3.3 10.10.10.0/24 exact
    
    s1.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
      Prefix                  Nexthop              MED     Lclpref    AS path
    * 10.10.10.0/24           Self                         100        64520 64500 I
    

    这样就够了吗?还不够!

    我们来查看一下所有的通告路由:

    root@esto# run show route advertising-protocol bgp 3.3.3.3 10.10.10/24
     
    s1.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
      Prefix                  Nexthop              MED     Lclpref    AS path
    * 10.10.10.0/24           Self                         100        64520 64500 I
     
    bgp.l3vpn.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
      Prefix                  Nexthop              MED     Lclpref    AS path
      1.1.1.100:1:10.10.10.10/32
    *                         Self                         100        64520 64500 I
      1.1.1.100:1:10.10.10.11/32
    *                         Self                         100        64520 64500 I
      1.1.1.100:1:10.10.10.12/32
    *                         Self                         100        64520 64500 I
      2.2.2.100:1:10.10.10.0/24
    *                         Self                         100        64520 64500 I
    

    我们也在通告/32路由。为什么会这样?细节决定成败。请记住,这是一个Inter-AS option B的方案,我们收到的/32路由是来自另一个PE,而不是来自CE,它们是作为MP-BGP路由接收的,而不是标准的BGP。

    Vrf-export策略只适用于从CE协议(bgp、bfd、isis、static等)学到的路由。因此,vrf-export策略对/32路由没有任何影响!我们不能在vrf-export策略中停止它们,不能在VRF级别上阻止它们。

    至少有两种方法来解决这个问题。

    第一个办法是在SDN GW和Tungsten Fabric之间的BGP会话上配置一个导入策略。这个导入策略只是根据route target匹配/32路由,并将no-advertise community添加其中:

    root@esto# show policy-options policy-statement imp-contrail | display set
    set policy-options policy-statement imp-contrail term a1-32 from community s1-vn
    set policy-options policy-statement imp-contrail term a1-32 from route-filter 0.0.0.0/0 prefix-length-range /32-/32
    set policy-options policy-statement imp-contrail term a1-32 then community add no-advertise
    set policy-options policy-statement imp-contrail term a1-32 then accept
     
    [edit]
    root@esto# show protocols bgp group contrail import | display set
    set protocols bgp group contrail import imp-contrail
    

    现在的结果是预期的结果:

    root@esto# run show route advertising-protocol bgp 3.3.3.3 10.10.10/24
     
    s1.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
      Prefix                  Nexthop              MED     Lclpref    AS path
    * 10.10.10.0/24           Self                         100        64520 64500 I
     
    bgp.l3vpn.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
      Prefix                  Nexthop              MED     Lclpref    AS path
      2.2.2.100:1:10.10.10.0/24
    *                         Self                         100        64520 64500 I
    

    另一种解决办法是:

    root@esto# show policy-options policy-statement rr | display set
    set policy-options policy-statement rr term s1-32 from community s1-vn
    set policy-options policy-statement rr term s1-32 from route-filter 0.0.0.0/0 prefix-length-range /32-/32
    set policy-options policy-statement rr term s1-32 then reject
    [edit]
    root@esto# show protocols bgp group rr export | display set
    set protocols bgp group rr export rr
    

    这次我们是在SDN GW和RR之间的BGP会话上配置一个导出策略。我们只是根据route target拒绝/32路由。

    两种解决方案得到的结果是一样的,选哪个由你决定。


    作者:Umberto Manferdini 译者:TF编译组
    原文链接:https://iosonounrouter.wordpress.com/2020/05/15/summarizingvm-routes-at-the-sdn-gw/



Log in to reply