1

enter image description here

I have couple of question in above design where i have typical clos network design and my leafs are configured for Cisco vPC for redendency and anycast gateway and running OSPF for underlay and BGP for overlay using ASN 65000

Question:

  1. what is the best way to connect ISP for internet access over eBGP using border-leaf, do vPC is better solution or without vPC (what are the advantage or disadvantage?)

  2. If my overlay BGP using ASN 65000 (private) and now i want to connect to ISP/Internet using my IANA registered ASN in that case how i can peer my border-leaf with ISP using eBGP peer? because i already have bgp 65000 process running on border-leaf?

Improve this question

2 Answers 2

Reset to default
1

VPC is a mechanism to achieve L2 multihoming. Connecting to an ISP with eBGP is very much an L3 exercise - and, as such, you're likely better off just establishing a second peering to another leaf. This is both a more scalable and simpler mechanism to establish connectivity. Leave VPC (or really any mLAG) for dual-attaching end-hosts and connecting to legacy networks.

Peering to an ISP router from an EVPN border leaf isn't going to look a whole lot different than a normal BGP connection and will be terminated within a VRF on on a standard L3 interface (i.e. not an SVI configured for anycast). You're going to use the local-as command to identify as your public ASN. The routes you receive from your upstream peer will be re-originated as type-5 EVPN routes to the other VTEP's in the fabric that are carrying the vrf in question (read: are importing the appropriate route-target).

Now - all that said - whether you want to propagate a full view within a vrf is a whole other question. It's absolutely possible, but a more typical design would have a series of dedicated border devices handling the full views and injecting defaults (or defaults plus some specific set of routes). In short, is it really necessary to carry 700K+ routes within a vrf on a leaf that's simply connecting a bunch of servers? This isn't really a point about EVPN, though - much the same would apply in a classical IP environment, MPLS, etc.

Improve this answer
12
  • @rnxrn Thanks for reply, I got your point to not use vPC and totally agreed, Question-1: Do i need point to point link between two border-leaf A & B router for iBGP peering between them? Question-2: If i don't configure public IP VTEP or Public iP Anycast Gateway then how other Leaf-1 & 2 will send traffic to border-leaf?
    – Satish
    Jun 27, 2020 at 3:52
  • 1.) The A and B leaves already have an MPBGP peering - either directly or, more likely, via an RR. If you're using an RR then it would obviously be incumbent upon you to make sure it has adequate resources to handle large RIB's. 2.) The other leaves are going to see MPBGP information from the various leaves in the fabric. In some cases that's going to be locally connected routes or, if the appropriate route targets are imported, the Internet routes. If the local leaves have global space directly connected then you'd be able to advertise those routes out the border leaves like any route.
    – rnxrx
    Jun 27, 2020 at 4:27
  • Thank you for wonderful explanation, For RR I have nexus 9336C-FX2 switches, what kind of resource RIB need memory or CPU? Tell me if I’m wrong RIB keep route info in memory or tcam, in EVPN routes are number of MAC addresses right? Let’s say I have 5000 host in future means 5000 MAC address so do you think it will overkill my RR (is there any number of best practice that how many Mac you can have in evpn segment or network)?
    – Satish
    Jun 27, 2020 at 15:07
  • 1
    If you're using all Cloudscale switches (Nexus 9300 -EX/FX/FX2/GX) you can reasonably handle tens of thousands of hosts on an EVPN fabric without too much drama. This potentially all goes out the window if you're trying to push 700K Internet routes, though. There are modes to do that, but using these modes will severely reduce the number of hosts you can handle. Check out the verified scalability guide - cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/93x/… .
    – rnxrx
    Jun 28, 2020 at 5:47
  • 1
    At least on the Nexus (in modern versions) both ASM and PIM bidir are supported. ASM isn't deprecated and is still in common usage in many (..if not most) environments. The configuration guide for EVPN on NXOS has the RP for the ASM set up as anycast on the spines. This is pretty much the most common implementation. Keep in mind that the role of multicast is carrying BUM traffic between interested leaves and that, in practice, the trees created in a spine-leaf topology will be really simple and pretty dense as most of your leaves will likely be subscribing to the same handful of MC addrs.
    – rnxrx
    Jul 3, 2020 at 23:41
1

ASNs

Regarding the ASNs, you have a lot of options. The least-complex choice is to treat ASN 65000 as a downstream private ASN customer of ASN 98765, accept Internet-bound routes from it, announce default (or DFZ, if you must) routes to it, and remove-private the ASN 65000 from AS_PATHs when you export them to your transit.

At the other end of the complexity scale is confederating so 65000 is a sub-as of 98765. This might make the network topology easier to understand, and routing protocol a little easier to express, while avoiding some MPLS-related obstacles in case you wanted to transport labeled VPN or INET traffic across both ASNs. I personally would not do this unless your network scales up considerably.

vPC for border

I assume the alternative you are considering is to not use vPC for that pair of border routers, and instead, configure/manage them separately.

Separate border routers is my recommendation for the border role because two separately-managed routers generally have less chance to fail simultaneously due to bugs or software/hardware upgrade complications.

In the border role, you get fewer advantages from technologies like vPC/StackWise/etc since it's likely all the neighboring routers will be speaking routing protocols. The benefits of things like MLAG or StackWise+EtherChannel are not there. You're also not trying to deliver L2 while avoiding STP. You pay all the MTBF & MTTR penalties for vPC but don't get most of the advantages it comes with in other roles such as top-of-rack.

I hope this helps.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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