Re: [huawei-nsp] huawei-nsp Digest, Vol 11, Issue 4
Yura Diesel wrote: > >1. Is there anybody out there? (Victor Sudakov) > Not alone, merely no answer No traffic at all? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ huawei-nsp mailing list huawei-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/huawei-nsp
[huawei-nsp] Routes imported from OSPF into MP-BGP
Dear Colleagues, Please look at the network diagram at http://noc.sibptus.ru/~sudakov/MPBGP2.PNG When I issue "display bgp vpnv4 vpn-instance XXX routing-table" on PE1, I see that the routes 10.67.75.216/29 and 10.67.80.4/31 are treated differently, and namely the route 10.67.80.4/31 is lacking any OSPF-related attributes (see below). Therefore (?) CE1 sees it as OSPF external route instead of internal. Why is that so? display bgp vpnv4 vpn-instance XXX routing-table 10.67.75.216 BGP local router ID : 172.21.16.41 Local AS number : 64580 VPN-Instance XXX, Router ID 172.21.16.41: Paths: 1 available, 1 best, 1 select BGP routing table entry information of 10.67.75.216/29: Label information (Received/Applied): 1247/NULL From: 172.21.16.1 (172.21.16.1) Route Duration: 00h14m22s Relay Tunnel Out-Interface: GigabitEthernet0/0/2 Relay token: 0x48007eed Original nexthop: 172.21.16.42 Qos information : 0x0 Ext-Community:RT <64580 : 64>, OSPF DOMAIN ID <0.0.0.0 : 0>, OSPF ROUTER ID <10.67.80.5 : 0>, OSPF RT <0.0.0.0 : 1 : 0> AS-path Nil, origin incomplete, MED 3, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255, IGP cost 20 Originator: 172.21.16.42 Cluster list: 172.21.16.1 Not advertised to any peer yet display bgp vpnv4 vpn-instance XXX routing-table 10.67.80.4 BGP local router ID : 172.21.16.41 Local AS number : 64580 VPN-Instance XXX, Router ID 172.21.16.41: Paths: 1 available, 1 best, 1 select BGP routing table entry information of 10.67.80.4/31: Label information (Received/Applied): 1247/NULL From: 172.21.16.1 (172.21.16.1) Route Duration: 4d23h08m06s Relay Tunnel Out-Interface: GigabitEthernet0/0/2 Relay token: 0x48007eed Original nexthop: 172.21.16.42 Qos information : 0x0 Ext-Community:RT <64580 : 64> AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255, IGP cost 20 Originator: 172.21.16.42 Cluster list: 172.21.16.1 Not advertised to any peer yet The routes are imported on PE2 by the BGP subcommand: # ipv4-family vpn-instance XXX import-route ospf 65 # So my assumption was that both should be imported as OSPF routes. Thanks in advance for any ideas. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ huawei-nsp mailing list huawei-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/huawei-nsp
Re: [huawei-nsp] A Multi-VPN-Instance CE and DN bit
Victor Sudakov wrote: > > I've spent a futile day trying to understand why in the topology shown > here: http://noc.sibptus.ru/~sudakov/MCE.PNG > the CE has a certain prefix in its lsdb but not in the routing table. > It was not being installed into the routing table because of the DN > bit set by the PE announcing the prefix. > > Now I know that the "vpn-instance-capability simple" on the CE makes > it ignore the DN bit and install the route. > > My question is, why is "vpn-instance-capability simple" not the > default behavior? What is the worst case scenario in the topology > above if it were the default? Well, I've found the topic more or less covered in https://eminent-ccie.blogspot.com/2009/09/ospf-capability-vrf-lite-command-down.html and https://community.cisco.com/t5/routing/where-to-configure-the-quot-capability-vrf-lite-quot-on-ce-or-pe/td-p/2812305 though they are not about Huawei. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ huawei-nsp mailing list huawei-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/huawei-nsp
[huawei-nsp] A Multi-VPN-Instance CE and DN bit
Dear Colleagues, I've spent a futile day trying to understand why in the topology shown here: http://noc.sibptus.ru/~sudakov/MCE.PNG the CE has a certain prefix in its lsdb but not in the routing table. It was not being installed into the routing table because of the DN bit set by the PE announcing the prefix. Now I know that the "vpn-instance-capability simple" on the CE makes it ignore the DN bit and install the route. My question is, why is "vpn-instance-capability simple" not the default behavior? What is the worst case scenario in the topology above if it were the default? Anyway, the left PE or the right PE would break the routing loop on seeing the DN bit (in each VRF), why does the CE have to look at it at all? Thanks in advance for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ huawei-nsp mailing list huawei-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/huawei-nsp
