RE: ACL VS Null Route [7:74267]
In a straight comparison, doing the NULL route is handled more efficiently on the router as its just standard L3 forwarding. If you do an ACL instead, the router has to do additional processing on the packet. If you're running something like a GSR or 7609 and the right LC where ACLs are handled in ASICs, then is probably doesn't matter which approach you use. I don't see configuration complexity being sufficiently more complicated in either case so thats a push. Depending on your network requirements and topology, ACLs might be better as you can check src and dst. The null routes will only catch the traffic based on dst. With Null routing, you can confirm the routing is operating via a show ip route and few simple pings. Doing the same sort of verification when using ACLs to block might be more difficult (depending on where you put the ACLs). Irwan Hadi wrote: I'm curious which one is better to use and why in case I want to filter some IP addresses that I don't want them to talk with my network, by using ACL or by null routing them? Say that I have around 50 to 100 IP addresses. Remember that I just want to filter the IP addresses, so I don't care about extended access-list. Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=74282t=74267 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: multiple ospf processes route insertion [7:73727]
Yup, it is a traffic engineering (service specific routing) problem. MPLS TE might be one way to solve this.I've honestly not looked at what it would take to get MPLS to run in this environment.However, enabling MPLS on the network would be a major undertaking so I've been looking at what other options might be possible. Zsomber has suggested using eBGP in order to enforce the policy (thanks). As the proposed network evolves, and direct links are built to many of the other ring routers, the eBGP solution would require running eBGP each link. This doesn't seem like the right path to take. An approach with using 3 OSPF processes and corresponding sub-interfaces leverages features we enable today. Granted we don't run 3 OSPF processes, but we do run one, so it may not be as big a deployment and operation stretch to go this route. As I surfed the net looking for other options, I ran across the concept of logical routers available in JUNOS (6.0?). I just glanced at the web site, and the multiple OSPF process concept seems similar to Juniper's logical router concept. I've attached the Juniper link for those interested. Apologies in advance for doing this on the cisco list... http://www.juniper.net/techpubs/software/junos/junos60/feature-guide-60/html/fg-logical-routers.html Howard C. Berkowitz wrote: I freely admit that I've lost the sense of the problem that actually needs to be solved, with all the discussion of the various tables. Before my brain started to reboot, however, it sounded like it was a traffic engineering problem. Has anyone looked at the OSPF Traffic Engineering extensions here? Also, I got an impression that people didn't want to use MPLS for a TE problem. Why? That's essentially what it's for. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73943t=73727 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
multiple ospf processes route insertion [7:73727]
I'm considering a routing architecture where devices in the network would run ~3 OSPF routing processes. I think each routing process will be handling the routing of non-overlapping address blocks and thus the routes they give to the forwarding table should be disjoint. However, I'd like to understand what happens if two processes each were to provide the same prefix to the forwarding table. Specifically, what are the rules to determine which prefix is put into the routing table? Also be interested in any learnings folks might have had when they've run multiple OSPF processes. Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73727t=73727 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: multiple ospf processes route insertion [7:73727]
Here's some more detail. Yes, assume the destination address (networks) represent the corresponding service. This is an existing production network where OSPF and iBGP are already in use for the existing (single) service. OSPF carries p2p and loopbacks; iBGP carries customer end-point networks. We want to overlay two other services. The paths the packets take to their destination, even if hosted on the same router, will be different. Further, when there's a failure in the network, the manner in which traffic gets re-routed will be specific to each service. An example might help. Consider some router R1 in this network. It has several connections to other routers in the network. It also has three interfaces each with a network assigned to it. Lets call these networks A, B and C and each is for a different service. Under normal conditions, traffic to A comes in via interface I1 and traffic to B and C comes in via interface I2. Now assume I2 fails. Traffic for A and B should come in over I1 and traffic to C stops being delivered. ACLs won't work in this situation for a number of reasons. Besides the configuration and operational issues, another requirement is that the end-points generating traffic to destinations in C will want to know when C is unavailable via I2. They'll want to know this so they can stop generating traffic or leverage some higher level (service specific) mechanism to address the failure. Running BGP as the IGP might work, but I'm not sure. I think it might need to operate in iBGP mode and I think it would require lots of policy filters on all outgoing advertisements and would probably require setting the next hop at each router. These are both typically not done when operating in iBGP mode. Further, I think one would lose the concept of IGP cost; the iBGP mechanism might allow one to construct a path between two end-points which satisfies the service policy, but if multiple paths exist, the concept of link cost would not be available.I guess running eBGP as the IGP could also work, but now we're talking configuring a unique AS for each router (which doesn't scale). One could see the path selected through the network via the AS_PATH attribute, but there still would be no concept of IGP cost. I've not come up with a way to solve this without moving to a model where theres an IGP and thus SPT for each service, which implies multiple OSPF processes. But I'm interested in other thoughts or options on this... Zsombor Papp wrote: Since you say you want to run one OSPF process for each traffic type, I assume the type of the traffic is defined by destination IP address. If this is not correct, then I would be curious to know what a traffic type is and how you will associate a traffic type with an OSPF process. If however my assumption is correct, then I can see several ways to solve the problem you cited as an example, with BGP or with a single OSPF process. Let me restate the problem for N=1: suppose there are 3 routers, R1, R2, R3, connected in a triangle. Both traffic A and B usually go directly from R1 to R2, but when that link fails, traffic A should go from R1 to R3 to R2, and traffic B should be dropped at R1. Solution with BGP: run BGP between R1-R2 and R1-R3, make the routes coming from R2 preferred, and filter out the routes corresponding to traffic B from the advertisements R3 sends to R1. Solution with single OSPF process: configure an access list on the link between R1-R3 that drops traffic B. :) Of course I might be missing something, so feel free to point out why these wouldn't work in your case. Thanks, Zsombor p b wrote: Using multiple processes might provide a way to implement policy at the link level. Typically, when one thinks of policy, one thinks of BGP. But what if your policy requires the ability to control what traffic can or can't go over a particular link? For example, consider two routers, that are interconnected by a direct link and a N-hop L3 path. Suppose traffic types A and B should typically go over the direct link but, if the direct link fails, traffic type A should be routed over the N-hop L3 path and traffic type B should not be forwarded. I don't believe there's a way to get this level of policy from a single OSPF process or a single OSPF process coupled with BGP. However, if you run multiple OSPF processes, say one for each interesting traffic type, and if you use BGP to set a network's next-hop to match the right OSPF RID, and for each link define a sub-interface (or not) for each OSPF process, then I think the above routing requirements might be supported. MPLS might work here, but I'm not sure. Suppose you have certain types of traffic that Zsombor Papp wrote: What are you trying to achieve with these ~3 OSPF routing processes? Thanks, Zsombor p b wrote
RE: multiple ospf processes route insertion [7:73727]
Lets go down another layer in your proposed BGP solution. The core topology will be along the lines of 5-10 routers in a ring. Lets say 7 routers, R1, R2, R3, R4, R5, R6 and R7 are connected in a p2p ring topology. Assume that there's one or more direct connections between R1 and R4. R4 has 3 other interfaces for networks A, B, and C. Each is a different service. Assume that R1 is connected to another cloud of routers and that traffic to networks A, B, and C will originate from this other cloud. The service routing requirements are as follows (from R1's perspective): * traffic to A should go follow the R1-R2-R3-R4 and/or the R1-R7-R6-R5-R4 path. * traffic to B and C should follow the R1-R4 path * when the link between R1 and R4 fails, B should be routed over the R1-R2-R3-R4 and/or R1-R7-R6-R5-R4 path. Traffic to C should stop. Provide some sample configs snipets for R1, R4 and an intermediate router which demonstrates how the proposed BGP solution would support the policy requirements. Thanks Zsombor Papp wrote: I am not sure what's the significance of the existing routing setup. Is there a desire to preserve any part of it? Your new example is pretty much the same as I described the problem, isn't it? So running BGP over I1 and I2 (just directly to the neighbor routers) would still work. Or is the requirement to be able to make such a decision at every single hop, not only at the end point? If so, using MPLS and Traffic Engineering might really be a better option, depending on how flexible your solution needs to be (ie. if there are thousands of possible paths and you want to allow only a few hundred, then that will be a nightmare even with TE). But let's consider a non-MPLS solution first. That would be what you call the BGP as IGP approach (although I assume you would still want to keep OSPF running to provide connectivity between the routers). The most important issue here is how you will make sure that the BGP sessions go up and down together with the links they correspond to. With eBGP, this is easy as you have direct control over the TTL of the BGP packets. With iBGP, you would probably have to use the physical interfaces' IP addresses for the BGP sessions (instead of the loopbacks, as it probably is currently). Unless you can limit the TTL of the iBGP packets (I don't remember if there is a way to do this in IOS). Another issue with iBGP is that routes learned from an iBGP peer are not advertised to another iBGP peer unless the local router is a route-reflector, so you would probably end up configuring every router except the end-points as a route-reflector. On a second thought, this is probably not a big issue, but I'll mention it anyway, maybe it rings an alarm bell in someone else's mind. :) I am not sure if setting the next-hop at every router would be necessary. The fact that in case of a link failure -- thanks to the filters applied to the BGP sessions corresponding to the still functional links -- there simply wouldn't be any routes advertised, seems to be sufficient. If so, the advantage of using iBGP would be that you could still rely on OSPF to select the path for the services that are still functioning. Of course, if a certain type of traffic is allowed on multiple links, then you will have to make sure that the OSPF metric is set so that the preferred link will be picked in case multiple links are available. Yes, maintaining the filters won't be great fun, but I suspect that it would be easier to comprehend than a per-serivce OSPF topology. The one AS per router requirement for eBGP doesn't seem to be very scary. An AS number is just a number, like the RID in OSPF, which you have one per router, so unless you expect to have 65000+ routers in this network, I don't see a problem with that. Also, you can prepend AS numbers to emulate the IGP cost. The bottle-neck of this approach might be the max allowed length for AS_PATH attribute. I seem to remember that it's 128, which is not a lot, but it's still better than old-style metrics in ISIS... Speaking of scaling, do you think that one OSPF process per service will scale? Since you will probably want to run all the OSPF processes on almost every link and pretty much every router, the load of running OSPF will be proportional to the number of services. Will the routers be able to keep up? What if they decide to add yet another service? Or three more? As for the ACLs, technically speaking, they do satisfify the requirement that the end-points need to be notified. There will be ICMP messages to this effect. You could extend the application to look for those (or write a separate small application). This might sound a bit crazy, but looking at the other options, I am not sure this is the worst one... :) Thanks, Zsombor p b wrote: Here's some more detail. Yes, assume the destination address (networks) represent
RE: multiple ospf processes route insertion [7:73727]
Here's some more detail. Yes, assume the destination address (networks) represent the corresponding service. This is an existing production network where OSPF and iBGP are already in use for the existing (single) service. OSPF carries p2p and loopbacks; iBGP carries customer end-point networks. We want to overlay two other services. The paths the packets take to their destination, even if hosted on the same router, will be different. Further, when there's a failure in the network, the manner in which traffic gets re-routed will be specific to each service. An example might help. Consider some router R1 in this network. It has several connections to other routers in the network. It also has three interfaces each with a network assigned to it. Lets call these networks A, B and C and each is for a different service. Under normal conditions, traffic to A comes in via interface I1 and traffic to B and C comes in via interface I2. Now assume I2 fails. Traffic for A and B should come in over I1 and traffic to C stops being delivered. ACLs won't work in this situation for a number of reasons. Besides the configuration and operational issues, another requirement is that the end-points generating traffic to destinations in C will want to know when C is unavailable via I2. They'll want to know this so they can stop generating traffic or leverage some higher level (service specific) mechanism to address the failure. Running BGP as the IGP might work, but I'm not sure. I think it might need to operate in iBGP mode and I think it would require lots of policy filters on all outgoing advertisements and would probably require setting the next hop at each router. These are both typically not done when operating in iBGP mode. Further, I think one would lose the concept of IGP cost; the iBGP mechanism might allow one to construct a path between two end-points which satisfies the service policy, but if multiple paths exist, the concept of link cost would not be available.I guess running eBGP as the IGP could also work, but now we're talking configuring a unique AS for each router (which doesn't scale). One could see the path selected through the network via the AS_PATH attribute, but there still would be no concept of IGP cost. I've not come up with a way to solve this without moving to a model where theres an IGP and thus SPT for each service, which implies multiple OSPF processes. But I'm interested in other thoughts or options on this... Zsombor Papp wrote: Since you say you want to run one OSPF process for each traffic type, I assume the type of the traffic is defined by destination IP address. If this is not correct, then I would be curious to know what a traffic type is and how you will associate a traffic type with an OSPF process. If however my assumption is correct, then I can see several ways to solve the problem you cited as an example, with BGP or with a single OSPF process. Let me restate the problem for N=1: suppose there are 3 routers, R1, R2, R3, connected in a triangle. Both traffic A and B usually go directly from R1 to R2, but when that link fails, traffic A should go from R1 to R3 to R2, and traffic B should be dropped at R1. Solution with BGP: run BGP between R1-R2 and R1-R3, make the routes coming from R2 preferred, and filter out the routes corresponding to traffic B from the advertisements R3 sends to R1. Solution with single OSPF process: configure an access list on the link between R1-R3 that drops traffic B. :) Of course I might be missing something, so feel free to point out why these wouldn't work in your case. Thanks, Zsombor p b wrote: Using multiple processes might provide a way to implement policy at the link level. Typically, when one thinks of policy, one thinks of BGP. But what if your policy requires the ability to control what traffic can or can't go over a particular link? For example, consider two routers, that are interconnected by a direct link and a N-hop L3 path. Suppose traffic types A and B should typically go over the direct link but, if the direct link fails, traffic type A should be routed over the N-hop L3 path and traffic type B should not be forwarded. I don't believe there's a way to get this level of policy from a single OSPF process or a single OSPF process coupled with BGP. However, if you run multiple OSPF processes, say one for each interesting traffic type, and if you use BGP to set a network's next-hop to match the right OSPF RID, and for each link define a sub-interface (or not) for each OSPF process, then I think the above routing requirements might be supported. MPLS might work here, but I'm not sure. Suppose you have certain types of traffic that Zsombor Papp wrote: What are you trying to achieve with these ~3 OSPF routing processes? Thanks, Zsombor p b wrote
RE: multiple ospf processes route insertion [7:73727]
Here's some more detail. Yes, assume the destination address (networks) represent the corresponding service. This is an existing production network where OSPF and iBGP are already in use for the existing (single) service. OSPF carries p2p and loopbacks; iBGP carries customer end-point networks. We want to overlay two other services. The paths the packets take to their destination, even if hosted on the same router, will be different. Further, when there's a failure in the network, the manner in which traffic gets re-routed will be specific to each service. An example might help. Consider some router R1 in this network. It has several connections to other routers in the network. It also has three interfaces each with a network assigned to it. Lets call these networks A, B and C and each is for a different service. Under normal conditions, traffic to A comes in via interface I1 and traffic to B and C comes in via interface I2. Now assume I2 fails. Traffic for A and B should come in over I1 and traffic to C stops being delivered. ACLs won't work in this situation for a number of reasons. Besides the configuration and operational issues, another requirement is that the end-points generating traffic to destinations in C will want to know when C is unavailable via I2. They'll want to know this so they can stop generating traffic or leverage some higher level (service specific) mechanism to address the failure. Running BGP as the IGP might work, but I'm not sure. I think it might need to operate in iBGP mode and I think it would require lots of policy filters on all outgoing advertisements and would probably require setting the next hop at each router. These are both typically not done when operating in iBGP mode. Further, I think one would lose the concept of IGP cost; the iBGP mechanism might allow one to construct a path between two end-points which satisfies the service policy, but if multiple paths exist, the concept of link cost would not be available.I guess running eBGP as the IGP could also work, but now we're talking configuring a unique AS for each router (which doesn't scale). One could see the path selected through the network via the AS_PATH attribute, but there still would be no concept of IGP cost. I've not come up with a way to solve this without moving to a model where theres an IGP and thus SPT for each service, which implies multiple OSPF processes. But I'm interested in other thoughts or options on this... Zsombor Papp wrote: Since you say you want to run one OSPF process for each traffic type, I assume the type of the traffic is defined by destination IP address. If this is not correct, then I would be curious to know what a traffic type is and how you will associate a traffic type with an OSPF process. If however my assumption is correct, then I can see several ways to solve the problem you cited as an example, with BGP or with a single OSPF process. Let me restate the problem for N=1: suppose there are 3 routers, R1, R2, R3, connected in a triangle. Both traffic A and B usually go directly from R1 to R2, but when that link fails, traffic A should go from R1 to R3 to R2, and traffic B should be dropped at R1. Solution with BGP: run BGP between R1-R2 and R1-R3, make the routes coming from R2 preferred, and filter out the routes corresponding to traffic B from the advertisements R3 sends to R1. Solution with single OSPF process: configure an access list on the link between R1-R3 that drops traffic B. :) Of course I might be missing something, so feel free to point out why these wouldn't work in your case. Thanks, Zsombor p b wrote: Using multiple processes might provide a way to implement policy at the link level. Typically, when one thinks of policy, one thinks of BGP. But what if your policy requires the ability to control what traffic can or can't go over a particular link? For example, consider two routers, that are interconnected by a direct link and a N-hop L3 path. Suppose traffic types A and B should typically go over the direct link but, if the direct link fails, traffic type A should be routed over the N-hop L3 path and traffic type B should not be forwarded. I don't believe there's a way to get this level of policy from a single OSPF process or a single OSPF process coupled with BGP. However, if you run multiple OSPF processes, say one for each interesting traffic type, and if you use BGP to set a network's next-hop to match the right OSPF RID, and for each link define a sub-interface (or not) for each OSPF process, then I think the above routing requirements might be supported. MPLS might work here, but I'm not sure. Suppose you have certain types of traffic that Zsombor Papp wrote: What are you trying to achieve with these ~3 OSPF routing processes? Thanks, Zsombor p b wrote
Re: IPv6 in the Enterprise Network [7:73667]
Howard C. Berkowitz wrote: Significant interest in Asia. Selected industries: HDTV, 3G wireless, new generation air traffic control HDTV? Do you have any thoughts or pointers as to why HDTV would be looking at v6? Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73792t=73667 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: multiple ospf processes route insertion [7:73727]
Using multiple processes might provide a way to implement policy at the link level. Typically, when one thinks of policy, one thinks of BGP. But what if your policy requires the ability to control what traffic can or can't go over a particular link? For example, consider two routers, that are interconnected by a direct link and a N-hop L3 path. Suppose traffic types A and B should typically go over the direct link but, if the direct link fails, traffic type A should be routed over the N-hop L3 path and traffic type B should not be forwarded. I don't believe there's a way to get this level of policy from a single OSPF process or a single OSPF process coupled with BGP. However, if you run multiple OSPF processes, say one for each interesting traffic type, and if you use BGP to set a network's next-hop to match the right OSPF RID, and for each link define a sub-interface (or not) for each OSPF process, then I think the above routing requirements might be supported. MPLS might work here, but I'm not sure. Suppose you have certain types of traffic that Zsombor Papp wrote: What are you trying to achieve with these ~3 OSPF routing processes? Thanks, Zsombor p b wrote: I'm considering a routing architecture where devices in the network would run ~3 OSPF routing processes. I think each routing process will be handling the routing of non-overlapping address blocks and thus the routes they give to the forwarding table should be disjoint. However, I'd like to understand what happens if two processes each were to provide the same prefix to the forwarding table. Specifically, what are the rules to determine which prefix is put into the routing table? Also be interested in any learnings folks might have had when they've run multiple OSPF processes. Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73789t=73727 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: Can block DHCP traffic at layer 2 switch? [7:73489]
Not sure what filtering capabilities you have on the switch, but you might be able to set all of the subscriber facing ports to block the forwarding out of DHCP DISCOVERs and REBINDS requests. I forget the details, but you can determine the directionality of the DHCP requests (DISCOVERs/REBINDs vs OFFERs/ACKs) based on the UDP port numbers and set in/out filters accordingly. The cable companies encode similar filters in your cable modem to prevent someone with a DHCP server in their home from hearing and responding to DHCP requests from the rest of the neighborhood. Lo Ching wrote: Dear All, We have configured DHCP server at the CORE switch and this will assign the ip address to the client located at edge switch. PC---edge switch-GE uplink---CORE---DHCP server (The network is pure Layer 2 network) But we are afraid that some end users will place their own DHCP server at the edge switch so it will interrupt the normal ip address assignment. Any method to block the unauthorized DCHP server? TIA. Lo Ching Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73503t=73489 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: Loopback Interface [7:73305]
terminate iBGP sessions on Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73339t=73305 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: igmpv2 sparse mode [7:73158]
The answer given seems a little thin. Here's how I understand this to work. When a router wants to join (*, G), it either needs to know the IP of the rendezvous point (RP) or a source generating the mulitcast traffic. Until the tree to the RP is built, the router only knows about the RP IP address. Thus, when the router wants to join (*, G), it does a routing loopkup for the RP IP address. The interface that would be used to reach the RP IP address is marked as the *incoming* interface, and then the router sends a JOIN (*, G) out this interface. This recursively happens, one router at a time, until the JOIN reaches the RP. If there's s source generating traffic, and once the tree to the RP is built, the router will start to receive multicast traffic. The router will therefore know a source for the multicast traffic, and could then, if so configured, build a tree to the source. The difference is now the router uses the source IP in its lookup into the routing table. The interface returned is now the incoming interface for the source and the interface over which the (S, G) JOIN is sent. Thus, using the source IP, the tree grows back to the source forming the SPT. The routing table referenced, when using PIM, can be the unicast routing table. However, if there's a need to apply policy unique to the multicast traffic (ie which paths to use to get to the RP or source IP), a second routing table can be referenced. This is the mroute table. Information typically inserted into this routing table is via static routes or MBGP (multicast BGP). In order to build the tree to the RP, the router must know the RP IP address. There are a number of ways for the router to become aware of the RP IP address. The first is for this information to be statically configured. Other approaches include the use of PIM's bootstrap message mechanism. A third approach is cisco's auto-RP approach. Antero Vasconcelos wrote: question In a PIMv2 Sparse Mode network, the incoming interface for a (*, G) mroute entry is calculated using: answer The address of a directory connected member of group G. anybody can explaim this answer. I4ve looked in the Books and still don4t undestand the question neither the answer!! thx in adv Antero *** Este email assim como os ficheiros que possa ter em anexo sao confidenciais e para uso exclusivo da pessoa ou organizacao para o qual foi enviado. Se recebeu esta mensagem por engano por favor notifique a Compta atraves do endereco [EMAIL PROTECTED] Esta mensagem foi verificada pelo sistema MAILsweeper nao tendo sido encontrados virus. http://www.mimesweeper.com MAILsweeper - Modulo da suite MIMEsweeper, solucao de filtragem de conteudos comercializada pela Compta SA. A Compta SA detem o mais alto nivel de especializacao MIMEsweeper, tendo sido reconhecida pela Clearswift como Premier Partner. *** This message is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this message in error, please notify Compta by emailing [EMAIL PROTECTED] quoting the sender and delete the message and any attached documents. This footnote confirms that this email message has been swept by MIMEsweeper for Content Security threats, including computer viruses *** Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73162t=73158 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: RFC 2547 vs. RFC 2764 VPNs [7:73048]
dre wrote: I, personally, do not want to get heavily into it. It's not mature technology, and it's all bad, IMO. There are a few solid technologies...and they are mostly the ones that were implemented first. Sure, MPLS-VPN with 2547 is great, but it scales horribly and is difficult to manage. It also is dependent on an MPLS core, with no route summarization, full IBGP with MP-BGP, and all the rest of the hooks. It uses two (and if you are using MPLS-TE, then three) labels to work, so it's big and kludgy. And you add all sorts of bugs and overhead to get it working. I'd be interested in understanding more why and how you think 2547bis does not scale. Are you refering to the number of routes the SP might need to carry or something else? If the former, then I'd agree. In the SP evals I've done of 2547bis solutions, one typically speaks vanilla eBGP between the CE and PE devices. I guess some SP support IGPs between the CE and PE, but that isn't practical from my perspective. At least from what I've seen, there's no need for iBGP or MP-BGP between the CE and PE devices. Certainly not iBGP. Don't understand the comment about route summarization and how it applies here. I'm curious if anyone has talked to their SP and has thought about leveraging MPLS carrier's carrier approach? Not sure how many SPs, if any, support this currently, but seems to have the right scaling properties if you're an ISP. And with the ability for eBGP to carry labels for BGP routes (see neighbor send-label), the CE-PE protocol remains vanilla eBGP, meaning there's no need for MP-BGP or LDP. Of course, now you may need to do iBGP or confed eBGP over the MPLS cloud, but that could be interepreted as a benefit. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73074t=73048 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Per-destination load balancing [7:72944]
Here's some text from CCO regarding CEF and using source and destination IPs to map a packet to one of a set of load sharing links: Configuring Per-Destination Load Balancing Per-destination load balancing is enabled by default when you enable CEF. To use per-destination load balancing, you do not perform any additional tasks once you enable CEF. Per-destination load balancing allows the router to use multiple paths to achieve load sharing. Packets for a given source-destination host pair are guaranteed to take the same path, even if multiple paths are available. Traffic destined for different pairs tend to take different paths. Per-destination load balancing is enabled by default when you enable CEF, and is the load balancing method of choice for most situations. The URL for the above is (watch wrap): http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_chapter09186a00800ca6ca.html#1000956 John Neiberger wrote: Priscilla Oppenheimer wrote: John Neiberger wrote: Tim Champion wrote: Could someone please confirm the following to be true (taken from CCO): Per-destination load balancing allows the router to distribute packets based on the destination address, and uses multiple paths to achieve load sharing. Packets for a given source-destination host pair are guaranteed to take the same path, even if multiple paths are available. For example, given two paths to the same network, all packets for destination1 on that network go over the first path, all packets for destination2 on that network go over the second path, and so on. Per-destination load balancing is enabled by default when you start the router, and is the preferred load balancing for most situations. It was my understanding that per-destination load balancing was based on the destination address only and not on the source/destination pair. If someone could clarify it would be much appreciated. Cheers Tim This probably depends on the switching mechanism in place. Fast switching, as I recall, simply caches the outgoing interface for any given destination so it's relying on the destination information only. Yes, fast-switching caches the outgoing interface for a destination. All packets to a particular destination go out the same interface. CEF works that way too if you use the default. CEF uses both the source and destination. I don't think that is true? CEF doesn't look at source addresses. I just checked this on our 7513 running 12.2(17a). If you use the command show ip cef exact-route sourceip destinationip you'll see the cached exit interface. If you do this with several source addresses going to the same destination when there are multiple paths you'll see that they use different exit interfaces. I wonder if the default behavior has changed as CEF has evolved? John Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73026t=72944 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
source specific m-cast error [7:72724]
I'm testing a setup using source specific multicast. On the RPF interface for the target source IP (192.168.25.25) I've configured the following command: ip igmp static-group 232.232.232.232 source 192.168.25.25 This seems to get the right messages forwarded up towards the source in order to get the SPT built. However, when I reboot this router, I see the following error message in the boot output: Accepting source reports only for groups in ssm range, 192.168.25.25 ignored and the above ip igmp static-group command is removed from the running config. Anyone seen this before or understand why the command is being removed? Should I be doing something different to statically cause the interface to join the SSM channel? Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=72724t=72724 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
OT: new CCIE requirement/step [7:72475]
Heard there's a new requirement between the CCIE written and lab. One now has to sing the following song on a street corner on Tasman Drive. Passing score is 740. http://puck.nether.net/~jared/gigflapping.mp3 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=72475t=72475 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
info on feature sets [7:72236]
Anyone have a pointer to a page which details what features are in each feature set. For instance, what are feature differences between the IP, IP Plus, and Service provider feature sets? Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=72236t=72236 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
was CEF and per packet load sharing [7:72258]
Consider two routers which have 3 GEs between them (no L2 device between them). Is it better to configure each of these GEs as a standalone L3 connection or to combine them GEs into an etherchannel (802.1ae?) bundle? My $0.02 would be to keep them at L3 and not run another protocol underneath to enable bundling. The question I've heard with this approach is how granular the load splitting works when splitting load across three interfaces. If CEF does per packet load splitting, would the load be (nearly) equal across the three interfaces (eg within 1-2% at all times)? When using per packet CEF, is there an issue with packets being received out of order? (Consider some flow where a large packet is sent over one interface and the following flow packet is small and sent over another interface. The small packet might be received completely before the large packet. Does per packet CEF address this issue?) I had heard that etherchannel (or the IEEE derivative) would support nearly equal load splitting across N interfaces. And it also defines a mechanism so that the receiving router would be able to detect and re-order packets which arrive out of order). Comments? Pointers to relevant docs? THanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=72258t=72258 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: policy based routing and backup [7:71482]
I'm not sure I understand completely why you want to do this, and it's been a while since I've dinked with PBR, but here's some thoughts on one might get this to work. I've done something similar, but not exactly what's below, so YMMV. Note, VRFs might fit better and I've listed some details on a VRF approach below. As I recall, one of the issues with PBR is that once you enable policy routing on an interface, normal L3 forwarding is completely bypassed.Thus, you can perform policy for the identified packets, but for any packets that you want handled normally, you're hosed or have to use the hack below. Also, the approach below requires that normal L3 forwarding is applied to the IP provided in the next-hop statement. I think some earlier IOS revs (12.0) would not perform a L3 lookup on the next-hop IP. Instead, it was assumed that the next-hop was an end-point to a locally connected interface. Config background: Assume that the subnet for the T1 between router A and the ISP's router is 10.0.0.0/30. Assume your router has the .1 address and the remote has the .2 address (10.0.0.2). Assume that you have a loopback define and its IP address is 10.100.0.1. Config snipets: On all of A's internal interfaces, you'll need to configured ip policy route-map dink. The route-map would look something like this: route-map dink permit 10 match ip address 10! match the target src IPs set ip next-hop 10.0.0.2 ! set next-hop to ISP's side of T1. ! route-map dink permit 20 set ip next-hop 10.100.0.1 ! for all other traffic, route ! to loopback interface Discussion: Ok, how does this work. Assume a packet arrives on an interface with PBR enabled and processed by the dink route-map. If the packet's source is in the target range, set the next-hop to 10.0.0.2. The router then does a L3 lookup on 10.0.0.2. If the T1 is up, 10.0.0.0/30 will be in the route table pointing to the T1 and thus the packet gets sent out the local T1. When this T1 is down, there won't be a route entry for 10.0.0.0/30. So when the router does the L3 lookup on 10.0.0.2, it matches the default and the packet is sent to router B. (Recall that the poster indicate defaults were sent from both ISPs). Note that this approach requires the router to perform a L3 lookup on the next-hop. This is required in order to get the failure scenario to work correctly. You'll need to confirm whether your IOS supports this functionality. Now, what about packets whose sources don't match the first part of the route-map and drop to the route-map's second stage? Presumably we want this packet to follow the standard L3 routing policy defined via LOCAL_PREF, etc. To do this, we need to get the packet processed by L3 as if it just arrived on an interface. One way to do this is to set the next-hop to the local loopback interface IP. The packet is queueed on that logical interface, and then gets processed via normal L3 forwarding. So the router forwards the packet to itself, L3 processes the packet, and then sends it out the desired interface. Note, I think all packets L3 forwarded by the loopback are process switched (you'll need to confirm if this is the case and whether the router has the horsepower to handle this.) In order to deal with the process switching overhead, one could instead forward the packet to a lollipop interface. This is basically a port which is wired back to another port on the same router. Suppose you have two FE ports free. You wire them together with a crossed cable, configure the interface as unnumbered, and then set the second stage of the dink route-map to set the next-hop the the FE interface. This eliminates the process switching problem, but leaves you with another single point of failure. I've never tried this lollipop interface stuff, but had heard it proposed a few times. You might want to look at VRFs instead and map packets with those certain sources into one VRF and all other packets into the global routing table. In the VRF, define two static defaults with different metrics. The lower metric default points to the local T1 and the second default with higher metric points to router B's enet IP. When the T1 is up, the lower metric default is in the VRF routing table and traffic goes over the T1. If the T1 fails, only the higher metric default pointing to B is in the VRF. Probably cleaner to do it this way... Hopefully, this will give ya some options to consider [EMAIL PROTECTED] wrote: Hi all. I have a question that I would like your opinion on. I have 2 routers each with a T1 to the upstream provider. Both routers are running eBGP to each provider only accepting partial routes and a default from each. In additon, each router is peering with each other via iBGP through a directly connected ethernet link which is also running ospf. ISPA ISPB | | | | RtrA---ibgp---RtrB
RE: policy based routing and backup [7:71482]
I think the results may depend on the rev of IOS and line card you're running. I did some lab testing with a 2610 running 12.2(4)T6 and it looks like this will work via the route-map (PBR) mechanism. It looks like, in this rev of code, that if the next-hop is not directly connected, then it will drop back to normal L3 forwarding. Further, it looks like if the match is not met, one can avoid the second stage in the route-map. If one falls off the end of the route-map, it looks like standard L3 forward is performed (at least in the testing I did) Below's the route-map I used in my testing: route-map dink permit 10 match ip address 10! access-list 10 permit a.a.a.a log set ip next-hop 192.168.0.14 ! equiv to your T1 interface Here's the message I get when the 192.168.0.14 interface is down or the match for a.a.a.a is not met: 01:57:04: IP: s=192.168.20.2 (Serial1/0), d=192.168.100.14 (Serial1/3), len 100, policy rejected -- normal forwarding Not sure about the verify-availability command. It looks like it requires your ISP to run CDP on the T1 to you. Wouldn't expect that to be typical. One other item you need to be aware of is if your router A is used as transit from a.a.a.a to other internal destinations. COnsider a packet from a.a.a.a going to some destintion c.c.c.c that is reached via some interface on router A. Since the policy gets applied first, the a.a.a.a packets will get forwarded out the T1 interface to the ISP, who will route them back to router A. One could configure all local destinations in the route-map before the test to match for a.a.a.a, but that's a real mess. If you move to VRFs, you should be able to leak your IGP routes into the VRF. [EMAIL PROTECTED] wrote: Hi P, Thanks for taking the time to respond to my email. The way the network is setup (right now) is that PBR is setup on the incoming interface into RtrA which will only get network traffic from a.a.a.a and never see any traffic from the incoming interface belonging to b.b.b.b. a.a.a.a is our lab traffic and I would like for it to use a different T1 (through RtrA) than what our real network is using which is a T1 on RtrB. I thought about implementing VRFs but I want to make sure that I cant do it any other way. In regards to the example you gave: route-map dink permit 10 match ip address 10! match the target src IPs set ip next-hop 10.0.0.2 ! set next-hop to ISP's side of T1. ! route-map dink permit 20 set ip next-hop 10.100.0.1 ! for all other traffic, route ! to loopback interface I went ahead and tried this. I setup a second route-map and pointed the next-hop to the internal loopback interface. I then shut down the T1 on the router and enabled debug to see what happend. The failover failed. Here is what the debug is showing: 1d01h: IP: s=a.a.a.a (FastEthernet0/0), d=198.6.1.1, len 92, FIB policy match 1d01h: CEF-IP-POLICY: fib for addr 10.0.0.2 is default; Nexthop rejected So as you can see, the second route-map failed to be used. When the packet came in, it matched the first route-map regardless of whether the next-hop was reachable or not. What about using the command ip next-hop verify-availability. I was reading up on this feature but I am not sure if I understand its use. Perhaps someone can fill me in. Thanks, Mario Puras SoluNet Technical Support Mailto: [EMAIL PROTECTED] Direct: (321) 309-1410 888.449.5766 (USA) / 888.SOLUNET (Canada) -Original Message- From: p b [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 2:45 PM To: [EMAIL PROTECTED] Subject: RE: policy based routing and backup [7:71482] I'm not sure I understand completely why you want to do this, and it's been a while since I've dinked with PBR, but here's some thoughts on one might get this to work. I've done something similar, but not exactly what's below, so YMMV. Note, VRFs might fit better and I've listed some details on a VRF approach below. As I recall, one of the issues with PBR is that once you enable policy routing on an interface, normal L3 forwarding is completely bypassed.Thus, you can perform policy for the identified packets, but for any packets that you want handled normally, you're hosed or have to use the hack below. Also, the approach below requires that normal L3 forwarding is applied to the IP provided in the next-hop statement. I think some earlier IOS revs (12.0) would not perform a L3 lookup on the next-hop IP. Instead, it was assumed that the next-hop was an end-point to a locally connected interface. Config background: Assume that the subnet for the T1 between router A and the ISP's router is 10.0.0.0/30. Assume your router has the .1 address and the remote has the .2 address (10.0.0.2). Assume that you have a loopback define and its IP address is 10.100.0.1
serial interface and pinging [7:71391]
Found this a bit unusual... have a feel for why it works this way, but figured I'd float this to the list for thoughts... Got two routers connected via a serial interface. R1 is assigned 192.168.2.1/30 on its serial R2 is assigned 192.168.2.2/30 on its serial On R1, do a debug ip icmp And then from R1, do a ping 192.168.2.1 (the IP on it's local serial interface). Interestingly we see the following: r2511#ping 192.168.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/73/84 ms r2511# 01:35:35: ICMP: redirect rcvd from 192.168.2.2 -- for 192.168.2.1 use gw 192.168.2.1 01:35:35: ICMP: echo reply sent, src 192.168.2.1, dst 192.168.2.1 01:35:35: ICMP: echo reply rcvd, src 192.168.2.1, dst 192.168.2.1 01:35:35: ICMP: echo reply sent, src 192.168.2.1, dst 192.168.2.1 01:35:35: ICMP: echo reply rcvd, src 192.168.2.1, dst 192.168.2.1 01:35:36: ICMP: echo reply sent, src 192.168.2.1, dst 192.168.2.1 01:35:36: ICMP: echo reply rcvd, src 192.168.2.1, dst 192.168.2.1 01:35:36: ICMP: echo reply sent, src 192.168.2.1, dst 192.168.2.1 01:35:36: ICMP: echo reply rcvd, src 192.168.2.1, dst 192.168.2.1 01:35:36: ICMP: echo reply sent, src 192.168.2.1, dst 192.168.2.1 01:35:36: ICMP: echo reply rcvd, src 192.168.2.1, dst 192.168.2.1 Two items of interest: 1) The router, when pinging it's local IP, actually transmits the packets onto the interface with source and destination being the interface's local IP address. The packets aren't looped internally, as I would have expected, but are looped via the remote router. 2) Router R2 sends an ICMP redirect suggesting a more efficient way to reach 192.168.2.1. Interesting behavior Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71391t=71391 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: bgp network sending subnet and more spec [7:71073]
Thanks. Yea, this is a real design. Can't do the /25 statics to the entity that IGP advertises the /24 as there are dual links and multiple hops and certain failure scenarios will cause traffic to get blackholed. Someone sent me a pointer off list (thanks Rob) that pointed me to the bgp inject-map command. Looks like it provides a way to get more specifics advertised if only the aggregate exists. Haven't had a chance to confirm this yet, though Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71240t=71073 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
bgp network sending subnet and more specifics [7:71073]
Suppose I have a router which has a subnet x.x.x.0/24 defined on some interface. Over one iBGP session I'd like to advertise the x.x.x.0/24 subnet. Over another iBGP session, I'd like to advertise x.x.x.0/25 and x.x.x.128/25. When I config three network statements for these subnets in BGP, only the /24 seems to be sent to the one iBGP peer. If I define a static null route for each subnet (x.x.x.0/24, x.x.x.0/25, and x.x.x.128/25), all three routes are advetised. Is there a way to get the /24 and two /25s sent without the null route? In actuallity, the /24 will be learned via some IGP, so can't use the nulls and the IGP will only send the /24 and not the two /25s. Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71073t=71073 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
bgp regexp [7:64872]
Using BGP regexp, what's the show ip bgp regexp ... command to show all routes which did not last come through AS NNN? For example, if there are BGP routes with the following AS_PATHs: 10 22 30 20 30 20 52 10 11 20 10 10 the command should return 10 22 30 and 10. Thanks PB Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=64872t=64872 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Who likes BGP? [7:64123]
Isn't it standard practice for two entities, when setting up a peering, transit, or partial transit relationship, to agree on what routes will be sent over the links and then develop route filters on each side accordingly? If this is done properly, then a misconfiguration on one side should not impact folks upstream or peering, no? Of course, if misconfiguration happens at multiple levels, then damage might affect multiple levels. Is there ever a time when one can't setup predefined routing filters on an eBGP connection because the set of advertisements expected over the link would be unknown? The Long and Winding Road wrote: Edwin R. Gonzalez wrote in message news:[EMAIL PROTECTED] http://news.com.com/2100-1009-990608.html yada yada yada :- the big point seems to be the misconfigured router incident, and it is highly unlikely that any system or protocol could have prevented that from happening. afterall, that router was trusted by it's neighbors, as it should have been. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=64151t=64123 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: BGP help needed., [7:62736]
Don't have any gear to test this on, but what if you put a network 1.1.1.1 mask 255.255.255.255 in your AS 200--AS300 eBGP peer? The route received from AS100 will populate the routing table and thus cause AS200's network statement to be satisfied and thus advertised. This may make 1.1.1.1 to appear, at AS300, to originate from both AS100 and AS200... Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=62751t=62736 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
basic bgp questions [7:62334]
Some question I had as I've been reading Doyle V2. 1) Question about next-hop-self. Suppose the router is purely an iBGP router-- it does not have any eBGP connections and is there is no redist into BGP. Does setting this command on a iBGP neighbor have any affect? If this router is a route-reflector does the behavior change? 2) There's mention that when a cluster uses two route reflectors, that the two reflectors must be configured with the same cluster ID (in order to avoid routing loops). If two route reflectors in a cluster use different cluster IDs, how is it that a routing loop can occur? 3) When configuring two route reflectors for a cluster, is it typical to make each reflector a client of the other? Why or why not? What issues, if any, would arise if the RRs are clients of each other? 4) When a route reflector is used and RR clients configured via a peer group, does the RR compute a single set of routes for reflection and sent to all RR clients? Does this mean a RR might reflect back to a client a route the RR learned from the client? 5) When associating a no-export community to an advertisement, is the route-map applied to the network statement or to the neighbor statement? Or can this be done via either mechanism? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=62334t=62334 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
bgp received-routes [7:62335]
I'm seeing what looks like inconsistent information being reported by a route reflector client (192.168.100.14). Below are two lines of output from debug ip bgp events and debug ip bgp updates: *Mar 3 09:06:26.265 UTC: BGP: 192.168.100.10 rcv UPDATE about 26.0.0.0/24 -- denied *Mar 3 09:06:26.265 UTC: BGP: 192.168.100.10 Prefix 26.0.0.0/24 rejected by inbound soft reconfiguration Notice that prefix 26.0.0.0/24 is received but is being denied/ rejected. This prefix is being advertised by this router to a route reflector (192.168.100.10), and it's being reflecting back (which appears to violate RFC 1996) Now, CCO reports that running the show ip bgp neighbor received-routes should show: (Optional) Displays all received routes (both accepted and rejected) from the specified neighbor. When I run this command on the RR client and looking for the routes received from the RR, I see the following: rtr-2514#show ip bgp neighbors 192.168.100.10 received-routes BGP table version is 13, local router ID is 192.168.100.14 Status codes: s suppressed, d damped, h history, * valid, best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *i22.0.0.0/24 192.168.100.10 0100 0 i *i24.0.0.0/24 192.168.100.5 0100 0 i Notice that 26.0.0.0/24 is not present. Is there a difference between denied and rejected routes? If, on the route reflector, I run show ip bgp neighbor 192.168.100.14 advertised- routes, I see that this route is in fact advertised: rtr-2610#show ip bgp neighbors 192.168.100.14 advertised-routes BGP table version is 17, local router ID is 192.168.100.10 Status codes: s suppressed, d damped, h history, * valid, best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 22.0.0.0/24 0.0.0.0 0 32768 i *i24.0.0.0/24 192.168.100.50100 0 i *i25.0.0.0/24 192.168.100.14 0100 0 i *i26.0.0.0/24 192.168.100.14 0100 0 i In order to be compliant with RFC 1996, when one does a show ip bgp neighbor X advertised-routes, one should never see X as the next hop, right? THanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=62335t=62335 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Secondary IP Addresses [7:58498]
Priscilla Oppenheimer wrote: p b wrote: Actually using secondaries and DHCP should be a non issue with any reasonable DHCP server platform. As you mention, in many versions of IOS the interface's primary IP address is used as the DHCP giaddr. If an interface has multiple secondaries, one just needs to configure the DHCP server to be aware that there are multiple scopes associated with the giaddr. But how does the server know which scope to use for the incoming requests when they all have the same giaddr? Priscilla Well, if you're going to put secondaries on an interface (physical or sub-interface), one could make the assumption that all relayed DHCP requests from that interface should be treated equally. Which means when the DHCP server gets the DHCP request, looks at the giaddr, sees there are multiple scopes associated with the giaddr, all of which *may be* applicable, and then assigns an IP address from one of the scopes to the end device. Now, if you wanted to segment end-users by function to a particular subnet, one could use sub-interfaces and then VLAN tag ports on the switch to correlate sub's traffic to a particular sub-interface. That's fine. But if you've initially assigned a /25 to the sub-interface and now need to grow it, you've got two options: a) replace the primary subnet with a larger block, which means replacing the primary on the sub-interface, renumber all the users, and update the DHCP server, or b) add a secondary block onto the sub-interface and then define a second scope on the DHCP server and related it back to the primary scope. Using this approach, there's no need to renumber. And if you find out you need to support 180 users, you could drop in a /26 to complement the /25. While you're making the changes, there's no impact to existing users on the interface. If you go option a), you'll need a /24 and lose some addressing efficiency. Option b) seems the way to go, but requires that the DHCP server support the concept of relating secondary scopes back to a primary. CNR supports this mechanism via the primary-scope construct. If your interface looks like: scope_10.0.1.0: scope details scope_10. Now, if one had secondaries on an interface (or sub-int) and wanted to vector a device (or particular types of devices) to a particular secondary, one needs to provide the DHCP server with more information. A sub-interface doesn't help There might be information supplied in the DHCP packet by the client to help identify the type of device, or DHCP information might be inserted by the Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58541t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Secondary IP Addresses [7:58498]
Argh. Tab and return doesn't work well in when posting through the web page Let me revise the last part of my message: If the interface (or sub-interface) looks like: int ethernet 4/0.42 ip address 10.0.1.1 255.255.255.0 ip address 10.0.2.1 255.255.255.0 sec ip address 10.0.3.1 255.255.255.0 sec Your scope logic in the DHCP server would look something like: scope_10.0.1.0: scope_10.0.2.0: primary-scope=scope_10.0.1.0 scope_10.0.3.0: primary-scope=scope_10.0.1.0 So when the DHCP packet arrived with the giaddr 10.0.1.1, it would match the scope_10.0.1.0. The DHCP server would be able to determine that there are really three scopes which might apply to this request. Now, if one had secondaries on an interface (or sub-int) and wanted to vector a device (or particular types of devices) to a particular secondary, one needs to provide the DHCP server with more information in order to make the right scope selection decision. There are several places where this additional information might be found: - on the DHCP server. One might encode MAC addresses of the devices in the DHCP server and specify a tag value for this device. Scopes would also have tags and a device's DHCP request could only match a scope of their respective tags matched. Encoding MACs is nasty. - look at the DHCP information provided by the client. The client device might encode information in its DHCP packet which the DHCP server can use to help make a scope selection decision (see DHCP Option 60 and many others). - look at the DHCP information inserted by the router when the packet was relayed. In certain environments, the router will insert special DHCP options (see DHCP Option 82) which the DHCP server can use to determine the type of device and hence appropriate scope. Regarding the question about what happens if the DHCP server is on the same ethernet segement as your clients. I've never run this configuration. A couple of thoughts on this: * This must be a single network as I don't think you'd want to have the DHCP server physically connected to each ethernet segment where DHCP services are being provided. * As soon as one wanted to support a second interface (and thus different set of interface and DHCP addresses) you'd need to move to a model where there is a giaddr. Otherwise, the DHCP server would not have sufficient info to pick an appropriate address. * I'd move the DHCP server onto its own subnet and use helpering and the giaddr approach. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58542t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Secondary IP Addresses [7:58498]
Ah, ok. I think I see some of the confusion. Recall that one can configure sub-interfaces with secondaries: int ethernet 4/0.10 ip address 1.2.3.1 255.255.255.0 ip address 2.3.4.1 255.255.255.0 secondary ip helper-address 99.88.77.66 int ethernet 4/0.20 ip address 3.4.5.1 255.255.255.0 ip address 4.5.6.1 255.255.255.0 ip helper-address 55.66.77.88 So the VLAN and trunking will bring a packet (DHCP broadcast as well) into the right sub-interface. If there's a single subnet on the sub-interface, then there should be a single (respective) scope on the DHCP server. If there's more than one subnet on the sub-interface, then DHCP server will need to know which secondary scopes are associated with the giaddr. Of course, if all of this seems like a major hassle, you could upgrade to 12.2 and use the ip dhcp smart-relay command. This command is suited to an environment where the (sub-)interface has secondaries and one doesn't want to have to configure the secondary to primary relationship on the DHCP server. When a DHCP device performs DHCP for the first time, it's DISCOVER will get helpered with the giaddr set to the primary interface IP. If the client tries 3 times and gets no DHCP OFFER, the 4th time the client sends its DHCP DISCOVER, the router will set the giaddr to one of the secondary IPs. This cycling through secondaries as giaddrs continues forever or until the DHCP server responds with an OFFER. Note, it will take some time for some clients to get an IP as they go through multiple DISCOVERs until they get an IP address. In an enterprise environment, I'd expect this would mainly kick in when the primary subnet has no free IPs on the primary subnet, and hence no OFFERs are made, and so devices would roll onto a secondary subnet. Priscilla Oppenheimer wrote: Thanks for all the info p b. It's very helpful. Regarding the first situation, where the DHCP server is on another segment and we're using a helper address to get the requests over to the server: We have established that if you use secondaries, the router puts its primary address into the giaddr field. I can see how that might not be a problem in some situations and could work well with a server with multiple scopes. As you mentioned, when increasing the original address space, multiple scopes work well. How about subinterfaces, though? I was under the impression that in that case, the router inserts the address of the subinterface. That way the DHCP server assigns an address in the right scope/subnet. This is helpful when devices are divided up into VLANs/subnets and you want to make sure a device in a particular VLAN ends up with an IP address for the subnet associated with the VLAN. If that's your goal, then you want to use subinterfaces. Secondaries don't work because of the issue with the router putting in its primary address only. But I may be making assumptions about the behavoir with subinterfaces. Let me know if I'm confused. Thanks! Priscilla p b wrote: Argh. Tab and return doesn't work well in when posting through the web page Let me revise the last part of my message: If the interface (or sub-interface) looks like: int ethernet 4/0.42 ip address 10.0.1.1 255.255.255.0 ip address 10.0.2.1 255.255.255.0 sec ip address 10.0.3.1 255.255.255.0 sec Your scope logic in the DHCP server would look something like: scope_10.0.1.0: etc.) scope_10.0.2.0: primary-scope=scope_10.0.1.0 details scope_10.0.3.0: primary-scope=scope_10.0.1.0 details So when the DHCP packet arrived with the giaddr 10.0.1.1, it would match the scope_10.0.1.0. The DHCP server would be able to determine that there are really three scopes which might apply to this request. Now, if one had secondaries on an interface (or sub-int) and wanted to vector a device (or particular types of devices) to a particular secondary, one needs to provide the DHCP server with more information in order to make the right scope selection decision. There are several places where this additional information might be found: - on the DHCP server. One might encode MAC addresses of the devices in the DHCP server and specify a tag value for this device. Scopes would also have tags and a device's DHCP request could only match a scope of their respective tags matched. Encoding MACs is nasty. - look at the DHCP information provided by the client. The client device might encode information in its DHCP packet which the DHCP server can use to help make a scope selection decision (see DHCP Option 60 and many others). - look at the DHCP information inserted by the router when the packet was relayed. In certain environments, the router will insert special DHCP options (see DHCP Option 82) which the DHCP server can use to determine the type of device and hence appropriate scope. Regarding the question
OSPF E1 or E2 [7:58454]
One of the cisco press books indicates one should use type 1 externals when the route is being advertised by 1 ASBR and type 2 externals when there's a single ASBR. Are there any issues if one uses type 1 external even when the route is being advertised by a single ASBR? It would seem useful, given the cost to the external is compatible with the costing used in the OSPF network, to use type 1 externals even if the route originates from a single ASBR. The benefit being able to get a meaningful cost value to the external. Is there any unexpected issues which might arise when doing this? Flooding of LSAs or SPF aren't imapcted if a route is an E1 or E2, right? Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58454t=58454 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF E1 or E2 [7:58454]
Comments inline: Howard C. Berkowitz wrote: At 5:00 PM + 12/3/02, p b wrote: One of the cisco press books indicates one should use type 1 externals when the route is being advertised by 1 ASBR and type 2 externals when there's a single ASBR. This is just plain wrong. The reason you have E1 and E2 is to have different routing policies. E1 enforces a closest-exit policy which gives a degree of load sharing. E2 enforces a best-exit policy. For example, you might have one fast link to an ISP and one dial backup link, or a primary and a backup provider. In both cases, you want an E2 because you always want to go to a specific exit UNLESS there is a failure. See ACRC (Chappel), page 217. Under E1 explanation ...Use this packet type when you have multiple ASBRs advertising a route to the same AS Under E2 explanation ... use this packet type if only one router is advertising a route to the AS... Are there any issues if one uses type 1 external even when the route is being advertised by a single ASBR? It would seem useful, given the cost to the external is compatible with the costing used in the OSPF network, to use type 1 externals even if the route originates from a single ASBR. The benefit being able to get a meaningful cost value to the external. Why? If there's only one connection to the outside, does the internal cost really matter if you have to go there? Is there no benefit to knowing the cumulative cost? Is there a benefit to knowing an E2 cost which has no cost meaning within the OSPF AS?As mentioned, there is only a single ASBR advertising this route, but there may be many paths to this ABSR. So if there's no overhead with using a type 1 here, why not use it and get the cost information? Is there any unexpected issues which might arise when doing this? Flooding of LSAs or SPF aren't imapcted if a route is an E1 or E2, right? Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58469t=58454 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF E1 or E2 [7:58454]
Sorry. Wasn't trying to suggest Howard was wrong, just providing the source of where I read the information. Everything Howard mentions makes sense. But when there's a single ASBR, it seems that there's no difference in E1 or E2 other than E1 give ya the cost to the external for free. I'm planning to use E1s in this situation but wanted to float this out to the list to see if there might be unexpected consequencies. From the feedback so far, there doesn't seem to be. Thanks Peter van Oene wrote: Some thoughts below On Tue, 2002-12-03 at 13:26, p b wrote: Comments inline: Howard C. Berkowitz wrote: At 5:00 PM + 12/3/02, p b wrote: One of the cisco press books indicates one should use type 1 externals when the route is being advertised by 1 ASBR and type 2 externals when there's a single ASBR. This is just plain wrong. The reason you have E1 and E2 is to have different routing policies. E1 enforces a closest-exit policy which gives a degree of load sharing. E2 enforces a best-exit policy. For example, you might have one fast link to an ISP and one dial backup link, or a primary and a backup provider. In both cases, you want an E2 because you always want to go to a specific exit UNLESS there is a failure. See ACRC (Chappel), page 217. Under E1 explanation ...Use this packet type when you have multiple ASBRs advertising a route to the same AS Under E2 explanation ... use this packet type if only one router is advertising a route to the AS... I'd go with Howard on this one ;-) E1 metrics simply let routers find the closest exit from the AS (so long as the external side of the metrics are relatively consistent) Are there any issues if one uses type 1 external even when the route is being advertised by a single ASBR? It would seem useful, given the cost to the external is compatible with the costing used in the OSPF network, to use type 1 externals even if the route originates from a single ASBR. The benefit being able to get a meaningful cost value to the external. Why? If there's only one connection to the outside, does the internal cost really matter if you have to go there? Is there no benefit to knowing the cumulative cost? Is there a benefit to knowing an E2 cost which has no cost meaning within the OSPF AS?As mentioned, there is only a single ASBR advertising this route, but there may be many paths to this ABSR. So if there's no overhead with using a type 1 here, why not use it and get the cost information? The path to the ASBR, or forwarding address if it isn't 0.0.0.0, comes out of the routing table. Hence, the router already knows the best path to ASBR. Having it represented in OSPF simply changes the outcome of the route selection process when there are mulitple entries for the same destination. In many cases, as Howard points out, you want all routers in the same AS to prefer ASBR1 over ASBR2 for the same destination. This is what routing policies are all about. In these cases, you simply set E2 metrics accordingly and accomplish your goal. Again, it's a matter of trying to figure out what you are trying to accomplish (what problem are you trying to solve) and picking the right tools to solve it. E1 and E2 are simply additional tools that can enable different routing strategies. Is there any unexpected issues which might arise when doing this? Flooding of LSAs or SPF aren't imapcted if a route is an E1 or E2, right? Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58479t=58454 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Secondary IP Addresses [7:58498]
Actually using secondaries and DHCP should be a non issue with any reasonable DHCP server platform. As you mention, in many versions of IOS the interface's primary IP address is used as the DHCP giaddr. If an interface has multiple secondaries, one just needs to configure the DHCP server to be aware that there are multiple scopes associated with the giaddr. The use of secondaries and the DHCP server logic to understand what scopes are associated with an interface is a useful feature when one might need to renumber users from one subnet to another. Or if one runs out of IP addresses on an existing subnet, one can simply add on a secondary subnet onto the interface and DHCP server without causing everyone to be renumbered. Darren S. Crawford wrote: Secondarys will really hurt you in a DHCP environment. The workstations on the secondary subnet will get their DHCP request forwarded with a source segment of the initial IP address on the interface. This was good ammo for me when I was in the same boat. HTH Darren At 10:52 PM 12/3/2002 +, Edward Sohn wrote: Thanks to all for the responses to my VPN connections. I have pretty much verified it will work in an active/failover setting... Now, I have an issue where I need to convince my customer that it's better to subinterface a fast ethernet port into two separate VLANs rather than add secondary IP addressing on the router. Now, from my understanding I thought that secondary IP addressing is traditionally not recommended. I thought I read somewhere that it creates instability for both networks and increases traffic. Now, I'm not certain, so correct me if I'm wrong. Thanks, Ed __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com + International Network Services Darren S. Crawford - CCNP, CCDP, CISSP Sr. Network Systems Consultant Northwest Region - Sacramento Office Voicemail (916) 859-5200 x310 Pager (800) 467-1467 mailto:[EMAIL PROTECTED] + Every Job is a Self-Portrait of the person Who Did It...Autograph Your Work With EXCELLENCE! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58507t=58498 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
OSPF forwarding address and route servers [7:58510]
Reading (yawn) RFC 2328 and there's mention of two uses of the forwarding address in external LSAs (section 2.3). The second use is where one makes an OSPF router a route server and it generates external LSAs with the forwarding address in each LSA set to the proper AS exit point IP. I guess the route server could specify multiple exit points for the same external network via a multiple respective LSAs and each router in the AS would compute it's path to the nearest exit point. Does anyone actually configure OSPF in this fashion? Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58510t=58510 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: mutliple RIP processes [7:58392]
Thanks. I had expected that router bgp ABC and router bgp XYZ did in fact start two processes. I hadn't tried applying a second router bgp XYZ to a config to confirm this worked. But as you point out, this isn't allowed (supported) and the router reports the error: router(config)#router bgp 1234 BGP is already running; AS is 123 I'm surprised that multiple IS-IS processes are not supported (but I don't know diddley about IS-IS so...) Any thoughts on why cisco decided to support multiple OSPF processes (or why other vendors did not)? Howard C. Berkowitz wrote: At 12:34 PM + 12/2/02, bergenpeak wrote: Anyone know why one can run only a single RIP process on a cisco router? Thanks I can't give you a precise reason, but some general comments. RIP was never intended for large systems where you might be able to make use of multiple processes. You could argue that having multiple IGRP processes was a way to add a primitive area structure, and then EIGRP needed compatibility. Even among the more advanced protocols, the multiple process per router has rather little applicability. OSPF is actually the exception in allowing multiple processes; BGP and ISIS do not. AFAIK, no vendor other than Cisco ever implemented multiple OSPF processes. Wellfleet/Bay/Nortel definitely did not. For things like performance benchmarking for the IETF and such, we most typically use Zebra or GateD UNIX boxes to generate traffic, or purpose-built high-speed testers. The high-speed testers typically don't really understand the protocol, but are playing back prerecorded traffic and responding to a very small set of messages. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58401t=58392 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF ABR question [7:57990]
LDSB synchronization or you don't. Consider ABR2. It will see type 1-5 LSAs from it's area 0. If ABR1 and ABR2 had a VL between them, ABR2 would pass all of these LSAs, intact, to ABR1 over the VL. Not quite true. ABR2 will not flood type 5 LSAs over a VL. However, since area 1 is not a stub, ABR 1 would see the type 5's anyway. ABR1 would be able to use area1 to send traffic to ABR2's area0. Assume there is no VL between ABR1 and ABR2. Instead, ABR1 learns about ABR2's area 0 via type 3-5 LSAs from ABR2. Well, type 3 LSAs are really the info found in type 1-2 LSAs but with just the RID information reflecting ABR2 instead of the originating router's RID. In your simple topology, this might work ok. However, your topology is simple. I've never really thought about the behavior you describe, mostly because I can't see where it makes sense, but I could imagine lots of control loops, particularly in areas with multi-abrs. When networks transition, you'd likely run into counting to infinity issues which OSPF doesn't really have a mechanism to deal with (ie hop count limits etc). So, I (still) don't see an issue if the ABR behaved as described above. Again, not in your simple topology as far as I can tell. Thanks for the thoughts so far. Be interested in more feedback on the above analysis. Peter van Oene wrote: On Sun, 2002-11-24 at 21:56, p b wrote: Consider this a question around the theory behind why OSPF did things a certain way. Somewhere along the way, Moy et. al. decided that there was an issue with an ABR processing a summary LSA. Based on that, they decided to make a design decision in OSPF to not allow this behavior. Intra area routing uses a distance vector methodology. Such mechanisms are prone to couting to infinity issues stemming from information feedback. Having a strict hierarchy prevents this. Apparently the restriction on ABR's processing of summary LSA information is being relaxed. This relaxation is described in the ID. You are right, the ID is slightly different than the context of my question. In the ID, the ABR is not connected to area 0, where's in my case, it is connected to area 0. But the concepts are similar-- there are times when an ABR should consider and use summary LSA information. The concepts are not that similar in my opinion. The non backbone connected ABR will not be capable of feeding back routing information into the backbone so long as regular ABRs ignore his summaries. There are valid designs that support this requirement. However, I do not see any valid reason to intentially fragment ones OSPF backbone. What problem does your topology solve? I'm not sure I understand your comment about adjacencies. ABR_1 does receive the summary LSAs from ABR_2 and stores these routes from these summaries in its LSDB for area 1. So this isn't an adjcency issue. So, still looking for an answer to the question. Why is it that an ABR can not use the information it receives in a summary LSA as part of the route selection process? There must be a reason why the spec indicates this is not allowed, and thus I'm looking for this reason. Doing so would create the potential for routing loops, particularly when two ABRs sit within the same area. In equal cost situations, there are no additional bits to designated whether a summary has passed through the backbone or not (like the ISIS up/down bit for example). The ID you refer to introduces this type of functionality for the non backbone connected ABR. Regarding the M$ comment. It really surprises me how often folks will cookie-cutter a design based on what was presented in the last book they skimmed and not try to understand a topic beyond what's needed to pass an exam. Just looking for some outside of the box thinking... The Long and Winding Road wrote: p b wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Thanks. But this doesn't really answer my question. I realize that area 0 is partitioned. I'm not looking for an answer to is there a rule that prevents this, but instead, what breaks if ABR_1 were to consider routes learned via a non-area-0 summary LSA in its computation of it's routing table? CL: sorry to be inflexible on this, but in my mind what you are
Re: OSPF ABR question [7:57990]
is the routing information received at this ABR different? The virtual link allows LSAs to flood through the non-backbone area. These LSAs allow the backbone area databases to remain identical for all routers in the area which is a necessity for link state protocols. Breaking this will more than likely lead to routing instability. Certainly in some basic topologies, you might be able to relax some rules and still provide stable routing, but the question is, what are you gaining with this topology? Consider two ABRs: area0ABR1area1ABR2area0 If the paritioning of area 0 gives ya the willies, assume they're connected together. It really doesn't matter. It matters entirely as you either have backbone LDSB synchronization or you don't. Consider ABR2. It will see type 1-5 LSAs from it's area 0. If ABR1 and ABR2 had a VL between them, ABR2 would pass all of these LSAs, intact, to ABR1 over the VL. Not quite true. ABR2 will not flood type 5 LSAs over a VL. However, since area 1 is not a stub, ABR 1 would see the type 5's anyway. ABR1 would be able to use area1 to send traffic to ABR2's area0. Assume there is no VL between ABR1 and ABR2. Instead, ABR1 learns about ABR2's area 0 via type 3-5 LSAs from ABR2. Well, type 3 LSAs are really the info found in type 1-2 LSAs but with just the RID information reflecting ABR2 instead of the originating router's RID. In your simple topology, this might work ok. However, your topology is simple. I've never really thought about the behavior you describe, mostly because I can't see where it makes sense, but I could imagine lots of control loops, particularly in areas with multi-abrs. When networks transition, you'd likely run into counting to infinity issues which OSPF doesn't really have a mechanism to deal with (ie hop count limits etc). So, I (still) don't see an issue if the ABR behaved as described above. Again, not in your simple topology as far as I can tell. Thanks for the thoughts so far. Be interested in more feedback on the above analysis. Peter van Oene wrote: On Sun, 2002-11-24 at 21:56, p b wrote: Consider this a question around the theory behind why OSPF did things a certain way. Somewhere along the way, Moy et. al. decided that there was an issue with an ABR processing a summary LSA. Based on that, they decided to make a design decision in OSPF to not allow this behavior. Intra area routing uses a distance vector methodology. Such mechanisms are prone to couting to infinity issues stemming from information feedback. Having a strict hierarchy prevents this. Apparently the restriction on ABR's processing of summary LSA information is being relaxed. This relaxation is described in the ID. You are right, the ID is slightly different than the context of my question. In the ID, the ABR is not connected to area 0, where's in my case, it is connected to area 0. But the concepts are similar-- there are times when an ABR should consider and use summary LSA information. The concepts are not that similar in my opinion. The non backbone connected ABR will not be capable of feeding back routing information into the backbone so long as regular ABRs ignore his summaries. There are valid designs that support this requirement. However, I do not see any valid reason to intentially fragment ones OSPF backbone. What problem does your topology solve? I'm not sure I understand your comment about adjacencies. ABR_1 does receive the summary LSAs from ABR_2 and stores these routes from these summaries in its LSDB for area 1. So this isn't an adjcency issue. So, still looking for an answer to the question. Why is it that an ABR can not use the information it receives in a summary LSA as part of the route selection process? There must be a reason why the spec indicates this is not allowed, and thus I'm looking for this reason. Doing so would create the potential for routing loops, particularly when two ABRs sit within the same area. In equal cost situations, there are no additional bits to designated whether a summary has passed through the backbone or not (like the ISIS up/down bit for example). The ID you refer to introduces this type of functionality for the non backbone connected ABR. Regarding the M$ comment. It really surprises me how often folks will cookie-cutter a design based on what was presented in the last book they skimmed and not try to understand a topic beyond what's needed to pass an exam. Just looking for some outside of the box thinking... The Long and Winding Road wrote: p b wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Re: OSPF ABR question [7:57990]
Thanks. Went back and read through some of the relevant parts of the RFC. I believe there is no routing loop issue if an ABR was to consider summary LSAs received from non-zero areas. (where consider means install routes from these type 3s. consider, above, does not mean propogate the summary info into area 0). I believe this would maintain the DV properties of the OSPF two-level hierarchy because the ABR would not re-originate the information that was already re-orignated at another ABR. In fact, if the ABR did install routes based on the non-0 summary LSA information, better paths to destinations might be possible. However, since the ABR doesn't advertise these better paths (remember, no taking non-0 summary info and sending into area0) these better paths are not visible to the backbone area. The result with an ABR using non-zero summary information in its routing table is that some intra area0 traffic might unexpectedly transit a non-zero area. Unexpectedly here means that the area0 SPF would compute a path to the destination, and from the SPF perspective, traffic would remain on area0. But when the traffic hit the ABR, it might forward the packets over the non-0 area as that's a better path towards the destination. A virtual link is the mechanism to formalize the use of a non-0 area for transit. The benefit of the VL mechanism over the thinking above is that a VL allows routers in area0 to be cognizant of the non-0 area as another way to reach destinations in area0 and thus include these costs into it's LSDB and SPF calcs. Compare an ABR including summary LSA information in it's routing table (what I've been asking about) and an ABR at the end if a VL. How is the routing information received at this ABR different? Consider two ABRs: area0ABR1area1ABR2area0 If the paritioning of area 0 gives ya the willies, assume they're connected together. It really doesn't matter. Consider ABR2. It will see type 1-5 LSAs from it's area 0. If ABR1 and ABR2 had a VL between them, ABR2 would pass all of these LSAs, intact, to ABR1 over the VL. ABR1 would be able to use area1 to send traffic to ABR2's area0. Assume there is no VL between ABR1 and ABR2. Instead, ABR1 learns about ABR2's area 0 via type 3-5 LSAs from ABR2. Well, type 3 LSAs are really the info found in type 1-2 LSAs but with just the RID information reflecting ABR2 instead of the originating router's RID. So, I (still) don't see an issue if the ABR behaved as described above. Thanks for the thoughts so far. Be interested in more feedback on the above analysis. Peter van Oene wrote: On Sun, 2002-11-24 at 21:56, p b wrote: Consider this a question around the theory behind why OSPF did things a certain way. Somewhere along the way, Moy et. al. decided that there was an issue with an ABR processing a summary LSA. Based on that, they decided to make a design decision in OSPF to not allow this behavior. Intra area routing uses a distance vector methodology. Such mechanisms are prone to couting to infinity issues stemming from information feedback. Having a strict hierarchy prevents this. Apparently the restriction on ABR's processing of summary LSA information is being relaxed. This relaxation is described in the ID. You are right, the ID is slightly different than the context of my question. In the ID, the ABR is not connected to area 0, where's in my case, it is connected to area 0. But the concepts are similar-- there are times when an ABR should consider and use summary LSA information. The concepts are not that similar in my opinion. The non backbone connected ABR will not be capable of feeding back routing information into the backbone so long as regular ABRs ignore his summaries. There are valid designs that support this requirement. However, I do not see any valid reason to intentially fragment ones OSPF backbone. What problem does your topology solve? I'm not sure I understand your comment about adjacencies. ABR_1 does receive the summary LSAs from ABR_2 and stores these routes from these summaries in its LSDB for area 1. So this isn't an adjcency issue. So, still looking for an answer to the question. Why is it that an ABR can not use the information it receives in a summary LSA as part of the route selection process? There must be a reason why the spec indicates this is not allowed, and thus I'm looking for this reason. Doing so would create the potential for routing loops, particularly when two ABRs sit within the same area. In equal cost situations, there are no additional bits to designated whether a summary has passed through the backbone or not (like the ISIS up/down bit for example). The ID you refer to introduces this type of functionality for the non backbone connected ABR. Regarding the M$ comment. It really surprises me how often folks will cookie-cutter a design based
OSPF ABR question [7:57990]
Consider the following topology: area_0---ABR_1area_1-ABR_2area_0 There are two area 0's. ABR_1 and ABR_2 will generate type 3 summary LSAs for the respective area 0s and flood the information into area_1. An internal router in area 1 will see the summary LSAs from ABR_1 and ABR_2, determine the best routes, and then insert them into it's routing table. Now consider ABR_1. It sees and stores in it's area 1 LSDB the summary LSAs it got from ABR_2. The OSPF spec indicates that ABR_1, however, should not forward this routing information into it's own area 0 connection. This is done to prevent routing loops. My question is this: What is the reason why ABR_1 can not use the routing information learned via ABR_2's summary LSA and install these routes into it's own routing table? Note, I believe if there was a virtual link between ABR_1 and 2, ABR_1 would learn via ABR_2 the same set of routes via summary LSAs and would be allowed to enter them into it's routing table. There must be a routing loop issue here, but don't see it. Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=57990t=57990 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF ABR question [7:57990]
Thanks. But this doesn't really answer my question. I realize that area 0 is partitioned. I'm not looking for an answer to is there a rule that prevents this, but instead, what breaks if ABR_1 were to consider routes learned via a non-area-0 summary LSA in its computation of it's routing table? Note, I'm also not asking why ABR_1 should not flood ABR_2's summary LSAs into ABR_1's area 0. So back to the scenario: all routers in area 1, including ABR_1, receive summary LSAs from ABR_2 which contain the routes from ABR_2's area 0. All non-ABR routers in area 1 will process the information injected by ABR_2's summary LSAs. These routers will install these routes into their routing table. These non-ABR routers will not realize there is an area 0 parition and will have reachability into both. (I've not tested this, but believe this to be true.) Since ABR_1 is an ABR with a backbone connection, it's not allowed to: - forward information from ABR_2's summary LSAs into it's area 0. - consider any routes found in ABR_2's summary LSAs as candidates for insertion into its routing table. My question is, what breaks if ABR_1 was to use the information found in ABR_2's summary LSA and put these into it's routing table? Note, it is possible for an ABR, which does not have an area 0 connection (hence it's an ABR between 2 or more non-zero areas) to consider and use summary LSAs in it's route installation process. (see Zinin's Cisco IP Routing, page 491; and http://www.ietf.org/internet-drafts/draft-ietf-ospf-abr-alt-05.txt) Thanks The Long and Winding Road wrote: p b wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Consider the following topology: area_0---ABR_1area_1-ABR_2area_0 There are two area 0's. CL: you have a partitioned area 0. can't have two area zeros in ospf. to quote from my favorite movie of all time, There can be only one ABR_1 and ABR_2 will generate type 3 summary LSAs for the respective area 0s and flood the information into area_1. An internal router in area 1 will see the summary LSAs from ABR_1 and ABR_2, determine the best routes, and then insert them into it's routing table. Now consider ABR_1. It sees and stores in it's area 1 LSDB the summary LSAs it got from ABR_2. The OSPF spec indicates that ABR_1, however, should not forward this routing information into it's own area 0 connection. This is done to prevent routing loops. My question is this: What is the reason why ABR_1 can not use the routing information learned via ABR_2's summary LSA and install these routes into it's own routing table? CL: there can be only one area zero. them's the rules. Note, I believe if there was a virtual link between ABR_1 and 2, ABR_1 would learn via ABR_2 the same set of routes via summary LSAs and would be allowed to enter them into it's routing table. There must be a routing loop issue here, but don't see it. CL: interarea routing must transit area 0. what you are not seeing is that you have a partitioned area zero, not two area zero's. you have broken ospf, and now you need to repair it. Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58006t=57990 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF ABR question [7:57990]
Consider this a question around the theory behind why OSPF did things a certain way. Somewhere along the way, Moy et. al. decided that there was an issue with an ABR processing a summary LSA. Based on that, they decided to make a design decision in OSPF to not allow this behavior. Apparently the restriction on ABR's processing of summary LSA information is being relaxed. This relaxation is described in the ID. You are right, the ID is slightly different than the context of my question. In the ID, the ABR is not connected to area 0, where's in my case, it is connected to area 0. But the concepts are similar-- there are times when an ABR should consider and use summary LSA information. I'm not sure I understand your comment about adjacencies. ABR_1 does receive the summary LSAs from ABR_2 and stores these routes from these summaries in its LSDB for area 1. So this isn't an adjcency issue. So, still looking for an answer to the question. Why is it that an ABR can not use the information it receives in a summary LSA as part of the route selection process? There must be a reason why the spec indicates this is not allowed, and thus I'm looking for this reason. Regarding the M$ comment. It really surprises me how often folks will cookie-cutter a design based on what was presented in the last book they skimmed and not try to understand a topic beyond what's needed to pass an exam. Just looking for some outside of the box thinking... The Long and Winding Road wrote: p b wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Thanks. But this doesn't really answer my question. I realize that area 0 is partitioned. I'm not looking for an answer to is there a rule that prevents this, but instead, what breaks if ABR_1 were to consider routes learned via a non-area-0 summary LSA in its computation of it's routing table? CL: sorry to be inflexible on this, but in my mind what you are asking is why doesn't OSPF behave in a way that it is not supposed to behave? Note, I'm also not asking why ABR_1 should not flood ABR_2's summary LSAs into ABR_1's area 0. So back to the scenario: all routers in area 1, including ABR_1, receive summary LSAs from ABR_2 which contain the routes from ABR_2's area 0. CL: no - becasue no adjacency can be formed between area 1 and area 2 routers. all adjacencies have to be formed between an area's ABR, which is connected to area zero. this changes if you either 1) unpartition area 0, with a tunnel or a virtual link or 2) set up a virtual link across either area 1 or area 2, ( which is probably the same as # 1 ) CL: you have an adjacency between area 1 and the area 0 it conects to, and area 2 and the area 0 it connects to. you do not get an adjacency between the area 1 and the area 2 routers. All non-ABR routers in area 1 will process the information injected by ABR_2's summary LSAs. These routers will install these routes into their routing table. These non-ABR routers will not realize there is an area 0 parition and will have reachability into both. (I've not tested this, but believe this to be true.) Since ABR_1 is an ABR with a backbone connection, it's not allowed to: - forward information from ABR_2's summary LSAs into it's area 0. - consider any routes found in ABR_2's summary LSAs as candidates for insertion into its routing table. My question is, what breaks if ABR_1 was to use the information found in ABR_2's summary LSA and put these into it's routing table? Note, it is possible for an ABR, which does not have an area 0 connection (hence it's an ABR between 2 or more non-zero areas) to consider and use summary LSAs in it's route installation process. (see Zinin's Cisco IP Routing, page 491; and http://www.ietf.org/internet-drafts/draft-ietf-ospf-abr-alt-05.txt) CL: I don't have the book you refer to. I did a quick read of the draft RFC in the link above. My quick read is that it looks to me that the authors are suggesting a reinterpretation of the definition and activity of an ABR to suit some particular situation that could also be solved other ways. Their examples do not match yours, so I won't comment further, except to wonder why it is that some folks want to take the Microsoft attitude - do whatever you want to don't bother with design. I mean, for goodness sake, if you want chaos, then set up using EIGRP ;- Thanks The Long and Winding Road wrote: p b wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Consider the following topology: area_0---ABR_1area_1-ABR_2area_0 There are two area 0's. CL: you have a partitioned area 0. can't have two area zeros in ospf. to quote from my favorite movie of all time, There can be only one ABR_1 and ABR_2 will generate type 3 summary LSAs fo
somewhat OT: using link distance for ospf cost [7:57744]
Wondering if anyone has set their OSPF link costs based on link distance instead of based on interface bandwidth. As link speeds increase, corresponding serialization delay decreases. So another possible value one might use for link cost is the distance of the link instead of based on interface bandwidth. Curious is anyone has done this and if this worked well, if issues where observed, etc. Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=57744t=57744 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
iBGF and failures (with some new info) [7:57548]
I had posted earlier in the week regarding some questions about iBGP, the routing table, and convergence. Have some more information and some more detailed questions. In terms of the design, the network consists of many routers all running iBGP in a direct mesh or through route reflectors. OSPF runs under these routers and just carries loopbacks and p2p networks. All iBGP route next-hops are use the router's loopback. Now, consider three iBGP routers in this network: R1, R2, and E. R1 and R2 advertise the same set of networks: N1, N2 and N3 via iBGP. OSPF advertises R1 and R2's loopbacks and p2p networks. E is a router on the other side of the network from R1 and R2. In normal operating mode, one will find the following in router E's routing table: N1 - R1_lo0 (via iBGP) N2 - R1_lo0 (via iBGP) N3 - R1_lo0 (via iBGP) R1_lo0 - e0 (via OSPF) R2_lo0 - e0 (via OSPF) This is as one would expect. Now, assume R1 goes down. OSPF quickly informs all networks that R1 has gone away, including it's loopback. Interestingly when I do a show ip route on E1, I see the following: N1 - R1_lo0 (via BGP) N2 - R1_lo0 (via BGP) N3 - R1_lo0 (via BGP) R2_lo0 - e0 (via OSPF) Notice that R1_lo0 is no longer a prefix that E knows how to get to. However, the iBGP next-hops continue to reference R1_lo0 as a next hop. These routes remain in E until BGP figures out, via BGP timers, that R1 has gone away. So, now the questions. 1) I *assumed* that the routing table process, once removing the R1_lo0 route, would have also removed any routes dependent on R1_lo0. This doesn't seem to be the case. Apparently, the route table process waits for BGP to attempt to re-insert its routes and only at that time does the route table remove the BGP routes dependent on R1_lo0. This seems somewhat improper behavior. Note, this behavior is also verifiable using two static routes pointing to two different next hops which are added/removed from OSPF. 2) I boated around on the cisco web site and found the following related URL (watch the wrap) http://www.cisco.com/en/US/tech/tk648/tk365/technologies_tech_note09186a0080094823.shtml Now it mentions two ways for the routing table to be updated: * The routing protocol periodically attempts to re-insert it's best routes into the routing table. This appears to be the behavior being observed with BGP above. * The second approach is where the routing table tracks when a routing protocol failed to get its route inserted into the table. The routing protocol is notified when the prefered path is removed from the route table and the routing protocol's path is then re-attempted to be inserted. Now, this is not exactly the configuration I have, but it's close. Instead of being a route learned by two different protocols, I've got two routes from the same protocol. I'd like the failed iBGP path to be removed, iBGP notified, and then have it re-insert the path to R2. Is there a way to cause this triggering event to the same protocol to happen? 3) From what I can tell no sync or sync in the iBGP config has no applicability here as the problem above is not related to the advertising of routes, but rather, it's around having BGP re-attempt to insert an updated best-path. Is there a way to tune the timers on how often BGP attempts to *insert* it's routes into the routing table? Thoughts? Curious if Juniper has the same issue. Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=57548t=57548 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
