Saif shaikh

So this is Sheikh, and I'm a B graduate from electronic telecommunication. And, you know, more of a brief about me is I'm very fascinated to network automation, network. I'm a network Cisco network guy. I'm a proper network guy by heart, but I started my journey with network engineering because this is something that really drives me crazy. And you talk about network to me for whole day long. I'll do that for you. But, again, I started my journey with a company called MicroSense that had a lot of wireless projects. And the post that I got an opportunity to work in a BFSI domain where I dealt with a lot of stock markets like NSE, BSE, MCX. And I was part of designing some casting for a vendor. So I was not working directly with NEC, but I used to take the feed from them. And then there were some vendors that we used to work with, like Grinksoft, Greenland Investments. And so the idea was these guys were making software where you could sit and trade on different exchanges so you don't have to go on different exchanges for trading. So this was a consolidated platform where you could trade. So and the idea was not for me not to trade, but I was a part of an infra team who would deal with not only networks, but also understanding how rack and stack and how things go from ground to hub. So, you know, dealing with Linux servers, ensuring that they are PTP enabled, NTP enabled because those were real-time applications, and I really enjoyed working there. And cutting it short, I've also been a tech engineer in Cisco. And now I'm a Cisco employee who's working for a product called Skylight Platform where we are working with all the service providers in India and outside India who are monitoring the network on a minute accuracy. So we're leveraging the protocol called TRAM. So we have a set of elements in Cisco in the Skylights product where you're working for full-stack observability. And the idea is to have ensured that you're delivering, you know, we're not helping the service providers to make their network fast, but we're helping them how can they make it fast. Yeah. That is all from my side.

Yeah, so describing the process of managing and implementing SD WAN technologies. Okay. So, I think SD WAN is the key right now for intent-based networking these days. You are with an intention, you can have a proper flow. I mean, SDN has been around since it hit the market, we are segregating the control plane with the data plane so that we can ensure that we have a centralized control over the network. So, the question I'm just repeating it once again is how would I manage an SD WAN technology? So, my head office would have all the set of components that SD WAN provides, the Wiptila provides, my VBond, my VManage, my VSmart on different locations. I would definitely need a CA server that would issue my server's certificates, and then ensure that I have a PKI done. And once that is done, that is the only hectic thing we do. And then once that is done, we just need to onboard all my v edges. I have two different transports, one MPLS, one Internet, and maybe one point-to-point connectivity. We're ensuring that we know the severity of the application and how important it is for an application not to have bad KPIs to ensure that we have good KPIs, and then we are using the best one. Anyways, if you ask about how I would process and manage it's pretty simple once it's installed and up and running.

So how would you optimize in a QS setting for a few IP infrastructure to mitigate packet loss or repeat usage? To mitigate packet loss or repeated usage, so why is voice traffic very fast compared to data? Your voice traffic is pretty fast, and your data can still wait, but your voice traffic cannot wait. So ensure that you give high priority and high DSCP values to these packets. When I implement a QS, I would have three things in mind. First, I have to classify it and then mark it. I have to classify it first, very first thing. So when I ensure that I'm classifying it on the source side, okay? This is my voice traffic or this is not my voice traffic. If it's not my voice traffic, I'm not marking anything. Then I decide on how to mark it. If I give it the highest priority, I want to ensure that these packets shouldn't get dropped because if they get dropped, they're useless, even if you retry them. So whenever these packets are in the queues, process them as soon as possible. With proper marking, I can implement those templates from point A to point B all the way, and then that's all. I mean, I think if I have enough bandwidth, I would never need a QS. This is my understanding, because I would never drop a packet. But if I have a bandwidth crunch, I would rather insist that the enterprise have enough bandwidth so that we never drop anything.

So how would you seamlessly run a transaction to transition from okay, from Cisco to Brocade there? I mean, I would rather see the placement of that Cisco switch, which is what it's really doing there. And, is it acting as a basic bridge of what it's doing? So I would first list down all the functionality that it's providing. And then, I would go open up my Brocade command line or take help from the Internet, okay. How would I configure, suppose if I'm doing STP in that switch, or if I'm doing a layout in that switch, or QoS, or so on? So I would just list down all those things. And then I would go back to that switch. And then I would study about it, okay, what things do I configure STP in network routing in this switch.

I've never used the poll for scripting. I'm using Python. I'm using bash. So, it's not limited to bash and Python. But, yeah.

Discuss the implications of COBIT framework. I'm really sorry, I don't know what your background is, but let's start with COBIT.

Can you explain the different voice? Yes. So, I'd love to speak on this for a long time. So, your OSPF is a, like, say protocol, which knows something. I'm sorry. Hello. So, OSPF is something that is a link-state protocol that knows the whole topology, the whole graph of the network, and then it would know what is happening right there in that area, not across the area. I mean, we would definitely segregate it once we make different areas. But at least in the area, I know what is happening, which link is connected to what link. So, the idea is to have when you say that it's a link-state flavor protocol. That means it is something that can keep updates about the whole network, whole topology, assuming that we are in the same area. Even if you're not, I at least know that to get to that area or get to that particular node, I have to reach out to my ABR or something like that. The best thing about OSPF is that it is scalable, very scalable. You don't need to think about when I compare it with the IGRP, my routing table is not large because I have an option to shorten down the routing table or something like that. OSPF is something that is when you compare it with other routing protocols, mostly with EIGRP, or BGP, because you won't compare it with EIGRP because it's the same, I mean, in the sense that it's both link-state protocols. So, I'm sure comparing link-state with distance-vector protocols. So, the only difference if you talk about OSPF and EIGRP is that OSPF is pretty scalable for large enterprises, large service providers, and it can be good for traffic engineering. It is very scalable. And apart from that, it's not that it's bad. It completely depends on the network. And that is it.

Yeah, so your VRRP being, you know, the first one of the FHRP, you know, you're the first stop to go out of your network. You ensure that if your gateway is dead, you will not route yourself. I mean, so the idea is to ensure that your gateway, your TOR, your top of the rack device is always up and running. So, we are really helped to ensure that if we have a virtual IP, we are literally ruling out link failure as well as physical box failure. So, we are actually one of the protocols that helps you to ensure that your top of the rack is always up and running, and that would ensure that your network is always up and running all the time.

Comprehensive project depends on how many routers I am replacing. And so, it is you know, I would rather take first of all, I would plan it up at how many sites I have and how many routers I have. I would create all those configurations in one go. Okay? And then, I would take a downtime and then push it. So the timeline, I'm not sure really what the question is asking me. But, I mean, if I can sense it, that if it's about time line, if you're asking me what is the timeline that I could see, I think I really need to know how many devices there are in the network. And if I take a common example, if I have 3 or 4 sites, I think it'll at least take 2 hours to do one site because I would perform a test, pre check and post check. But in doing all those things in the production live, I would rather do it in the test lab first than to remove the VRRP and ensure that my existing service is not impacted. But I would rather have to take a downtime because I'm removing VRRP reconfiguration, and all the devices beneath will talk to that virtual IP, which I have given you. So, yeah, the idea is to have the number of sites that we have. So if it's about one site, and at least we will at least need 2 to 3 hours to ensure with pre check, post check.

The key element to focus on when making network modifications are definitely testing bits. Every change I've made, we've already checked in the labs first. We do a test lab first and then make the modifications, listing down all services that will be impacted. That's first of all, listing down all the services that the site or network is providing and then ensuring that those are not getting impacted, and what other redundancy I can create.

SD WAN technology, as I said, impacts an architecture. I think it's an intent-based networking. You know, it's a way of packet traffic flowing. Your control plane has become so sharp that it knows if this particular traditional WAN link, which is taking approximately low KPIs, or something like that. My application needs anything below 1 ms 2 ms. So I would rather route it through that way. And that benefit it provides over MPLS, you know, is maybe MPLS is not always the best option. I think it completely depends on the provider. Again, if your MPLS is faster than your traditional wired WAN architecture, then it's good.