Archive for the ‘RIP’ tag
ROUTE Notes – Routing IPv6
Study Questions
- Why would anyone develop a version of RIP that supports IPv6?
I have no idea. Boredom, maybe. Whatever the case, it works just like RIPv2, which is pretty scary.
- In EIGRP for IPv4, there are several requirements for two routers to neighbor up. Which of those is not true for EIGRP for IPv6?
The two routers don’t need to be in the same subnet. The concept of the link local address takes care of that need since neighbors always share a common medium like an Ethernet segment or a serial link.
- I configured EIGRP for IPv6 on my completely IPv6 router, but it’s not working. Nothing happens. What’s going on?
For one, you have to do a no shutdown as an EIGRP subcommand; by default, EIGRP for IPv6 is in a shutdown state. Another reason could be that a router ID hasn’t been set; EIGRP for IPv6 still uses the IPv4 addresses to establish a router ID, so you may have to set one manually.
- I tried to configure EIGRP for IPv6 with the network statements, but it’s not taking the command. What gives?
You actually configure EIGRP for IPv6 (and RIPng and OSPFv3) the “new way” by using the interfaces. Try doing a ipv6 eigrp X as an interface subcommand.
- When redistributing one IPv6 IGP into another, what kinds of routes will and won’t be redistributed?
Only routes discovered via the original IGP will be redistributed. Connected routes, even the ones configured in the original IGP, won’t be redistributed. Link local addresses and local routes will also NOT be redistributed.
- Show me a simple RIPng config.
R1(config)#ipv6 router rip PROC-NAME
R1(config-rtr)#int f0/0
R1(config-if)#ipv6 rip PROC-NAME enable
- Show me a simple EIGRP for IPv6 config.
R1(config)#ipv6 router eigrp 8
R1(config-rtr)#router-id 1.1.1.1
R1(config-rtr)#no shutdown
R1(config-rtr)#int f0/0
R1(config-if)#ipv6 eigrp 8
- Show me a simple OSPFv3 config.
R1(config)#ipv6 router ospf 4
R1(config-rtr)#router-id 1.1.1.1
R1(config-rtr)#int f0/0
R1(config-if)#ipv6 ospf 4 area 0
- How do you include connected routes when redistributing one IGP into another in IPv6?
Use the include-connected directive in the redistribution command.
- In EIGRP for IPv6, what address shows up as the next hop in the routing table?
The link local address of the advertising router.
What Command Was That
What command is used to…
- …show all the IPv6 routes?
show ipv6 route
- …shows the status of OSPFv3 neighbors?
show ipv6 ospf neighbor
- …shows the status of RIPng neighbors?
There is none; RIPng doesn’t have neighbors.
- …shows a route to a specific prefix?
show ipv6 route prefix::/length
An Interesting Problem with Multiple DCs on a Stick
We talked about running multiple data centers on a stick back in August, which is where you have multiple logical pairs of client and server VLANs on a single CSM for different tiers or functions. The big point of the article was that you had to do some fancy forwarding to get a server-initiated connection from one server VLAN to appear out the appropriate client VLAN. Well, we ran into an interesting issue with the given solution.
Let’s set up a scenario. Check the diagram for an overview. We have many pairs of client and server VLANs each with a firewall interface as the gateway into the DCOAS. Let’s just focus on just one, though — client VLAN 101 and server VLAN 102. In VLAN 101 is ServerA (not pictured) with an IP of 1.1.101.45; in VLAN 102 is our web farm that needs to connect to ServerA to drop off some data. We add a static route on ServerA pointing traffic for 1.1.102.0/24 back through the CSM.
When you try to connect from the web farm, though, it just times out. Why is that?
Remember that weird forwarding vserver that we had to use to get traffic to come out of the right client VLAN? Well, that’s stabbing you in the eye right now. When the web server initiates a connection, it sends traffic to the server VLAN IP of the CSM. The forwarding vserver grabs the new connection and load balances it to its only RIP, which is the IP of the firewall. What happens when any good firewall accepts traffic destined on an interface destined for a host out of the same interface? It drops the packet, and, eventually, the server times out.
What’s the fix, then? There are a few that come to mind. The first may be to just move ServerA to another network segment. Another may be to change the process around a bit by having ServerA pull the data instead of it being pushed since client-initiated connections will work like a champ.
A really outrageous one would be to set up another forwarding vserver that has only ServerA as it’s serverfarm. You would then add a static route in the web servers pointing to ServerA through that VIP, which would foward it over.
On the CSM, you’d do something like this.
serverfarm SERVERA-SF no nat server no nat client real 1.1.101.45 <--- ServerA inservice vserver SERVERA-VS virtual 1.1.102.5 any vlan 102 serverfarm SERVERA-SF inservice
On the server, you would add a static route to ServerA through 1.1.102.5. If you’re using some brand of Linux, you’d do this.
route add 1.1.101.45 gw 1.1.102.5
Don’t forget the static route on ServerA.
Send any Peeps questions my way.
ACLs and HSRP, BGP, OSPF, VRRP, GLBP…
Here’s a handy list of ACL entries to allow your devices to speak routing protocols, availability protocols, and some other stuff. We’ll assume you have ACL 101 applied to your Ethernet inbound; your Ethernet has an IP of 192.168.0.1.
- BGP : Runs on TCP/179 between the neighbors
access-list 101 permit tcp any host 192.168.0.1 eq 179
- EIGRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.10
access-list 101 permit eigrp any host 224.0.0.10
- OSPF : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.5; also talks to 224.0.0.6 for DR/BDR routers
access-list 101 permit ospf any host 224.0.0.5
access-list 101 permit ospf any host 224.0.0.6
- HSRP : Runs on UDP/1985 from the source interface IP to the multicast address of 224.0.0.2. I’ve seen in the past that it runs on UDP/1985, but I didn’t find any evidence of that in a quick Google for it. Can someone verify?
access-list 101 permit udp any host 224.0.0.2 eq 1985
- HSRP version 2 : Runs on UDP/1985 from the source interface IP to the multicast address of 224.0.0.102.
access-list 101 permit udp any host 224.0.0.2 eq 1985
- RIP : Runs on UDP/520 from the source interface IP to the multicast address of 224.0.0.9
access-list 101 permit udp any host 224.0.0.9 eq 520
- VRRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.18
access-list 101 permit 112 any host 224.0.0.18
- VRRP-E : This is a Foundary thing according to readers, and runs on UDP/8888 from the source interface IP to the multicast address of 224.0.0.2
access-list 101 permit 112 any host 224.0.0.2 eq 8888
- GLBP : Runs on UDP from the source interface IP to the multicast address of 224.0.0.102
access-list 101 permit udp any host 224.0.0.102
- DHCPD (or bootps) : Runs on UDP/67 from 0.0.0.0 (since the client doesn’t have an address yet) to 255.255.255.255 (the broadcast).
access-list 101 permit udp any host 255.255.255.255 eq 67
If anyone else has one to add, do so in the comments.